[x/operator] Consensus Key Redundant Storage

[MaxMustermann2]

• Whenever an operator opts into the x/dogfood AVS, their consensus key is recorded in x/operator.
• They have the right to change the consensus key and replace it with another. Such a transaction can be sent many times within one epoch; the design is structured such that the last active key and the most recent replacement key are retained in x/operator.
• However, this design does not work if a key is replaced immediately upon opting-in. In such a case, x/operator retains (unnecessarily) the original key and the new (active) key.

[MaxMustermann2]

The most obvious solution is to have x/dogfood callback x/operator to indicate that a key has been activated. If a key has never been activated, it does not need to be stored. However, that is an additional field added and seems like overkill.