Implement delegator slot reservation

[wojcik91]

No description provided.

[wojcik91]

@mpapierski I did implement the solution we've discussed to the issue of handling both legacy and updated SeigniorageRecipientsSnapshot:

• added a named key to the auction contract to store the version flag
• check for presence of flag when reading the snapshot for arbitrary era

I've also added a method to add this new named key and migrate current snapshot to new version as part of protocol upgrade, but this is a part of the codebase I'm unfamiliar with, so I'm not sure if this is the correct approach.
I know my changes introduced some test failures, but before I delve into debugging those please let me know if this is a valid solution or if I should approach the topic differently.

[mpapierski]

Looks solid as implemented, although you should take into account an optional migration of named keys etc which would not happen at 2.0.0 release.

[wojcik91]

@mpapierski I implemented the fixes we've discussed + some other stuff I found. I also added a migration test.

[EdHastingsCasperAssociation]

@darthsiroftardis can you review this, paying particular attention to entity migration on / off integration

[darthsiroftardis]

@EdHastingsCasperAssociation Looks good to me, from the entity on/off side, the only impact is when auction data from its named keys, but its using entity addr, and the changes on my end are such that the handling of the on/off bit happens within the get named keys function, so overall nothing I saw raised a flag

I would normally just approve the PR, but, I know we are still iterating over the name