`VaultRotationResponse` Does not need to contain the `old_key` and `new_key`

[kylezs]

Currently we have

/// A response of our request to rotate the vault
#[derive(PartialEq, Eq, Clone, Encode, Decode, RuntimeDebug)]
pub enum VaultRotationResponse<PublicKey: Into<Vec<u8>>, Transaction: Into<Vec<u8>>> {
    Success {
                // remove
        old_key: PublicKey,
                // remove
        new_key: PublicKey,
        tx: Transaction,
    },
    Failure,
}

However, returning these keys is unnecessary. This response is sent back alongside the ceremony_id. In vault_rotation_response() like here: https://swimlanes.io/u/Ptsk3nVj-

The state chain is able to associate the request with the response.

Some supporting ideas after discussing with @andyjsbell :

• The redundancy it provides as a "check" that the CFE has the keys is pretty weak. An attacker can very easily send back the correct public keys here, even if they were using different ones (not sure what attack this would be part of, but nonetheless)
• If the CFE does have the wrong pubkeys (which will be an extremely rare, some might say impossible event for honest nodes - and why would a dishonest node say that it has the wrong pubkey, even if it has the right private key share?), it most likely will fail to sign (because it has the wrong priv key share) i.e. this is already checked, no need to complicate/bloat the system with extra state / checks
• The SC could provide an error back to the CFE to say that it does not have the correct keys. What happens here? There's no way for the CFE of a node with the wrong idea of the pubkeys to recover from here, so it would just be restarted, and get the correct pubkeys from the chain (and just hope that it has the correct priv key shares - if these are corrupted, unlucky)

[morelazers]

It would be clearer if the swimlane included all the necessary parameters, but I think I understand the gist and agree with the above.

[andyjsbell]

closed with https://github.com/chainflip-io/chainflip-backend/pull/493/