Implemented cooldown for OperatorFee change

[br41nl3t]

Taking into account that we cannot redeploy Storage contracts on the Parachain, we're not able to add new variable to the StakingStorage contract in order to keep track of operatorFee change delays, so I've implemented a workaround.

We have uint96 variable operatorFee, the operatorFee itself is in range [0, 100] (takes 7 bits), so we can easily store timestamp for cooldown end inside the same variable, which looks like this:

uint96 combinedData = (uint96(block.timestamp + cooldownDelay) << 7) | operatorFee;

cooldownDelay here is stakeWithdrawalDelay not to introduce a new variable

To get operatorFee from this variable:

uint96 operatorFee = combinedData & 127;

To get timestamp from this variable:

uint96 timestamp = combinedData >> 7;

[botnumberseven]

Well, that's a workaround for sure, but i don't like it really.
As now we have "operatorFee" value in OperatorFeeUpdated event, which is not an operator fee really, but a combined value. I can see how it will cause issues down the road. The simplest one - without reading this specific PR, I don't see a way how someone can find out that operatorFee value is not an operatorFee. Does not look to me we follow best practices with that change.

[br41nl3t]

@botnumberseven, I added separate getters for both variables and updated event to have operatorFee + timestamp separately. I don't see how else this complicates life for the external users, so feel free to elaborate

[botnumberseven]

I'm looking onto changes in abi/StakingV2.json

OperatorFeeUpdated event has identityId, nodeId and operatorFee. Where operatorFee has been changed from unit8 to uint96. Based on this ABI it's not clear that operatorFee is a combined value which needs to be bit split.
I guess I'm missing something, right?

[br41nl3t]

@botnumberseven, it's just that I didn't push new ABIs yet.

Anyways, there is another implementation in #209. Closing this one