The initial version of Firefox background task mode launches each background task invocation in a temporary ephemeral profile that is removed from the file system as the task exits (and cleaned up after the task in extremis).

We have new use cases that would like to use existing technologies (Remote Settings, Nimbus, Firefox Messaging System) that use standard persistent storage solutions (mainly IndexedDB) to efficiently incrementally update (Remote Settings) or prevent spamming users (Firefox Messaging System). This ticket tracks allowing to annotate select background tasks to use a persistent, per-task, per-installation profile to support these use cases.

My desired API would ape that of the existing backgroundTaskTimeoutSec, which exposes the setting in the task definition JSM directly. However, doing so isn't easy in this case, because the switch controlling persistent profile is needed extremely early in startup: long before we can evaluate the task definition JSM to extract its exports, etc.

Therefore, we could either give up on this approach and hard-code a list of special background tasks (like we do with IsUpdatingTaskName), or we could try for a multi-stage startup process, that:

1. launches firefox --backgroundtask ... with a temporary ephemeral profile if a default profile will be selected by the profile service
2. consults the task definition JSM
3. in case a persistent profile is required, relaunches firefox --backgroundtask ... --profile ... or similar to arrange for the persistent profile to be used

The latter is slick but complicated. Having investigated it enough to sketch the bones, I expect to not pursue it any further due to time pressure.

Temporary profiles mean different things in different contexts; for
example, the term is used in testing and the test harnesses.

I think ephemeral conveys what we're after well and will be easier to
search for.

This allows the profile service to handle XRE_PROFILE_PATH,
--profile, etc as normal before choosing a "default" background task
profile directory.

Depends on D149917

This is mostly straight-forward: some background tasks will have a
consistent profile location. Right now, those tasks are determined by
their task name, but in the future we could make this more flexible.

A few technical notes:

1. I elected to not assume (or provide) a directory service provider
   in the relevant helper, mostly to ease future commits that might
   pull this functionality forward in the startup process.

2. I don't salt these profiles, which might expose a vulnerability.
   But I don't want these background task profiles to appear in
   profiles.ini, so I don't see a way to salt. The installation
   hash does provide some protection against guessing the exact
   location.

Depends on D149918

https://hg.mozilla.org/mozilla-central/rev/0daa6975305d
https://hg.mozilla.org/mozilla-central/rev/1a66d0e98dbe
https://hg.mozilla.org/mozilla-central/rev/164bbd196bb6