Make 4S and Cross-Sign bootstrapping more reliable

[bwindels]

Summary

Task for fixing #13542 with the following approach.

We create a new idb store "operations" to persist user intent for operations that are not atomic or who's state otherwise can't be easily reconstructed to see if it happened already (e.g. migrations). In here we store a bootstrap operation and keep track of how far (e.g. created locally, uploaded all account data, uploaded keys) we got with it. We also split up the bootstrapping into two operations, one for 4S and one for cross-signing.

We also store pending account data uploads in a new account data store. This allows us to retry account data uploads in the future. This will need to be opt-in, because current usages of setting account data expect failure and their UI needs to be adjusted to retrying.

When starting a bootstrap operation, we store everything locally, the operation and account data values.

We don't automatically run the operation in the background, but don't design this out. We do need an API to restore the operation and rerun it to completion from a toast notification.

Steps

• remove support for curve25519 4S keys as they are obsolete but require signing
• remove signing 4S keys with xsign master key
• PR the above
• split up bootstrapping 4S from bootstrapping xsigning
• PR the above
• refactor both bootstrappings:
  • ensure we have finished catchup sync so we can assume up-to-date AD
  • split into 2 separate steps
    • generating account data & keys to upload (sync)
    • actually upload the AD & keys (and upload keys last) (async)
• PR the above
• add account_data store in which pending account data can be stored
• add an AccountData class that deals with updates to this store
• add method to add new pending account data. We calculate the hash of the content (SubtleCrypto.digest("SHA-256", anotherjson(content)) so we can check later if something else overwrote the account data for a given type, and we have a way of comparing incoming AD with the pending one.
• on sync, handle remote echo of account data by comparing content hashes.
  • remove pending AD on matching remote echo?
  • mark pending AD as conflicted on non-matching remote echo?
  • emit an event on updates
  • allow to query current state of pending AD
• PR the above
• add operations store
• store 4s/xsign bootstrapping progress in operations, with content hashes for pending AD, and pub keys for xsign
• make bootstrapping return an BootstrapOperation object on which progress can be followed, rather than just a promise when finished
• rebuild BootstrapOperation from operation in persistence
• have BootstrapOperation observe account data
• restore existing bootstrap operations after catchup sync and show toasts if sanity checks don't work out
• migrate currently broken bootstrappings to operations? we will need to passphrase to detect this
• retry from toast actions
• PR the above

[turt2live]

Closing as these days we don't really use trackers/epics like this anymore.

I'll share this with the crypto team to see if there needs to be issues created off of this, however.