Rolling PR for the clients engine

[linabutler]

The clients engine is used to send and receive commands for sync
engines, like wiping data and resetting Sync metadata. These are
sent in a client record's commands list, and acked by removing
the command from the list. The engine syncs twice: once at the
start of the sync, to apply any incoming commands from other clients,
and once at the end, to upload any outgoing commands added as a result
of the sync.

Our implementation is based on Desktop's, but works a little
differently:

• Instead of holding commands in memory, ours pulls outgoing commands
  directly from logins and Places. This follows the approach of
  bookmark restore on Desktop, which writes a flag into Places to send
  a wipeEngine command on the next sync.
• Our engine relies on the embedding app to supply it with a Settings
  struct containing info about the current client.

Thanks to these two changes, our engine doesn't need to store any state
itself. This means it can be used as a short-lived object that's dropped
after it syncs, like our other syncable stores, and not a long-lived
singleton as on Desktop.

Closes #1380.

Pull Request checklist

• Quality: This PR builds and tests run cleanly
  • cargo test --all produces no test failures
  • cargo clippy --all --all-targets --all-features runs without emitting any warnings
  • cargo fmt does not produce any changes to the code
  • ./gradlew ktlint detekt runs without emitting any warnings
  • swiftformat --swiftversion 4 megazords components/*/ios && swiftlint runs without emitting any warnings or producing changes
  • Note: For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGES_UNRELEASED.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due dilligence applied in selecting them.

[linabutler]

@thomcc This is just a start (needs to be wired up to the sync manager, and tests!), but does the design seem sensible to you?

[linabutler]

OK, I think this is ready for review! 😅 The latest PR splits the implementation in two:

• A clients engine, in the sync15 crate. It depends on a lot of sync15 internal structs, and, rather than expose them publicly, it made more sense to lift the engine into this crate. It exposes a CommandProcessor trait for handling the actual commands.
• An implementation of a command processor in the sync manager, which does all the heavy lifting.

Also a few things to note:

• We use the FxA device ID as the client record ID, per @mhammond's proposal.
• A command can be applied, ignored, or unsupported (I wonder if that should be spelled Retry?). Unsupported commands—say, Wipe("passwords") for a client that only supports "bookmarks" and "history", or a totally new command that the client doesn't support at all—get put back in that client's record, on the chance that it's upgraded to support that data type at a later time.
• Any errors syncing the clients engine abort the entire sync, including failing to run a command. This seems a bit excessive, but avoids weirdness like accidentally merging our local bookmarks with new ones on the server, instead of erasing all our bookmarks and starting over, if another device sent us a Wipe("bookmarks") command.

[linabutler]

Also, this still needs tests! 😂

[rfk]

Unsupported commands—say, Wipe("passwords") for a client that only supports "bookmarks" and
"history", or a totally new command that the client doesn't support at all—get put back in that
client's record, on the chance that it's upgraded to support that data type at a later time.

Naively, this sounds kind of risky...are there any circumstances where delaying one of these commands and executing it much later could do weird things to the user's sync data?

[linabutler]

Naively, this sounds kind of risky...are there any circumstances where delaying one of these commands and executing it much later could do weird things to the user's sync data?

Good question!

• WipeAll and ResetAll only wipe and reset the engines we support at the time we process the command, so those won't be delayed.
• Wipe("engine-that-we-dont-support-yet") and Reset("engine-that-we-dont-support-yet") are trickier. Let's say Fenix gets a Wipe("passwords") command, and puts it back in its record because it doesn't sync logins. Later, Fenix gets support for logins, and automatically imports them from Fennec before syncing. When the user upgrades, all their logins will get imported from Fennec, and then wiped when sync runs.

This could either be:

• Desirable, if the user restored their logins on another device, and expects all devices to now reflect that view. If Fennec still had old logins, those will either be reuploaded or merged. (This is more of a concern with bookmark restores—we'll merge instead of wiping and starting over with the server's data!)
• The worst thing to have happened! What if they accidentally erased all their passwords, and the Fennec import was the last copy they had?

For other commands...it depends on the command. But perhaps erring on the side of dropping the command would be the prudent choice.

(This also doesn't impact round-tripping commands that we don't understand for other clients...those will still get reuploaded).

[thomcc]

This looks great with some nits addressed and rebased again.

[linabutler]

(I just rebased, added history wiping, and some tests, but didn't address any of the other feedback yet. I'd also like to add a test for apply_incoming, which will involve rejiggering a few things so that we don't have to mock the whole world to make an Engine).