Deletion token improvements

[corrideat]

Problem

For certain operations, like deleting files, we currently use bearer tokens. The issue with those is that they're unique and randomly generated, so we need to store them, which is inefficient: it bloats the contract chain and the state.

This could be even more of an issue for ephemeral messages (#1900), since, ideally, we want per-message permissions (to reduce the amount of information stored by the server), but we don't want to store a large number of keys / tokens.

Solution

One solution to this, which we could then also apply to files, is to take some inspiration from things like BIP-32 and derive tokens deterministically, based on a seed. This is how it could work:

1. The user generates a seed, which could be stored in their identity contract or in the KV store.
2. The seed is used to generate a token, taking some input such as the CID (hash) that it's for or the tuple (contractID, height), or some other input that identifies a specific message / file. For example, an HKDF could be used, and browsers natively support SubtleCrypto.deriveBits.
3. The token is sent to the server and stored (note: the server shouldn't have the seed, otherwise we can avoid this entirely and just use signatures)
4. For operations that require authentication (e.g., deletion), the user re-computes the token based on their seed and the other input (e.g., the CID) and sends that to the server.

Note: we probably want the ability to rotate seeds, just like we can rotate other keys. This means that we still need a way of figuring out which seed is supposed to be used for any given message.

[corrideat]

Why we'd want to rotate seeds: for the same reason we have password rotation / changes. In the event of a suspected password compromise, a user could change their password. If they are successful at preventing an account breach by this, we'd likely also want to rotate the seed(s) used for token generation. This is so that an attacker won't be able to delete or modify messages (although, depending on how we implement this, they may still be able to delete or modify previous messages, before the seed rotation took place).