Protect from creating megolm backup that may not be trusted by future sessions.

In order to decide if a backup can be trusted to **upload** local keys, one of the following condition should be true:

1. The backup is signed by the user's master cross-signing key (and the later is trusted)
2. Or the backup is signed by a verified device belonging to the same user
3. Or by deriving the public key from a private key that it obtained from a trusted source. Trusted sources for the private key include the user entering the key, retrieving the key stored in secret storage, or obtaining the key via secret sharing from a verified device belonging to the same user.

Out of the 3 options, the number 1 is more powerful as it will still be valid even if the device that created the backup gets deleted.

Scenario: You login a new session and verifiy it, so the MSK is trusted. As MSK signs the backup it will be trusted.
The signature from the device that created it is deleted thus the signature can't be check.

There are cases were you could verify the new session properly without getting the backup decryption case from any trusted source:
- The 4S doesn't contain the backup decryption key
- The other session you verified against doesn't have the secret or failed to send it.

**Given all of that, it could be an idea to ensure that created backups are signed with the msk?** And error if the msk private key is not known.
Currently the SDK signs the backup with the device, and if the private msk key is known it will add the msk signature. So it could create a backup only signed by the current device.

Additional Notes:
The `crypto-sdk` offers an API `verify_backup` to check if a remote backup can be trusted. But the `rust-sdk` is not using it.
Maybe on the assumption that the 4S is always complete? or that all other devices have all the secrets in cache?
Not sure how well the EX API would interoperate with existing clients that can have partial setups. From the look of it the EX applications only upload to backup if they are able to decrypt from it

Start by examining the rust-sdk backup upload and signing path, then compare it with the crypto-sdk verify_backup API and the partial-secret scenarios described in the issue. Done means the trust conditions for newly created backups are defined, including behavior when the master-key private key is unavailable, and compatibility with existing clients is assessed.

Written by the indexing model from the issue text.