SFrameTransform needs more key management than "set"

[bifurcation]

Right now, the way SFrameTransform is provided with keys via the setEncryptionKey method, which replaces the key used for encryption. In applications where keys are rotated (e.g., on join/leave), this one method is insufficient.

The typical lifecycle is as follows:

• A next key is distributed for a given sender.
• Receivers add the next key for receiving (in addition to the current key).
• Once a sufficient fraction of receivers have added the key, the sender begins using the next key to send.
• Once the sender starts using the next key, the receivers can delete the current key.

So we probably need an idea that SFrameTransform has multiple keys active at once (when receiving) and more of an "add / remove" semantic than a "set" semantic.

[youennf]

The principle is the following:

1. On sender side, setting the encryption key means using it from now on, the old key can be forgotten. This is really a set semantics.
2. On receiver side, setting the encryption key means making it available as SFrame key material. It will be used when keyID matches. So it is really an add semantics. There is no remove now as the transform can potentially forget the past key that was used.

[bifurcation]

OK, but (a) that's not what the spec says ("Set key with its optional keyID as key material"), and (b) if that's the case, why not be explicit?