ValidatorManager is PoA when deployed on its own

[cam-schultz]

Why this should be merged

To implement a multi contract validator manager, ValidatorManager functions that modify validator state are restricted to the "specialization" contract (e.g. PoSValidatorManager) via an onlyAdmin modifier. This is identical to how OpenZeppelin Ownable contracts work, which is the only meaningful logic contained in PoAValidatorManager. Given these similarities, folding the PoA use case into ValidatorManager directly is the simpler approach.

One consequence of this design is that in the PoA case, only the admin may deliver ICM messages to complete validator registration or removal. This can of course be worked around, but I'm not convinced this is a use case worth supporting, since permissionless interaction with a PoA contract is antithetical.

How this works

Removes PoAValidatorManager and modifies ValidatorManager to implement OwnableUpgradeable.

How this was tested

Updated e2e subnet conversion flow to support `

• deploying a standalone ValidatorManager (i.e. PoA)
• converting to PoS by deploying a separate PoS contract, and setting that as the ValidatorManager's owner

How is this documented

Updated README and class diagrams

[iansuvak]

I really like this simplification -- even if the majority of the deletion delta is from the .sol and bindings, I think it also makes it simpler to explain and being able to verbally distinguish between "staking manager" and "validator manager' without the "validator manager" term being overloaded.

[iansuvak]

I really like this simplification -- even if the majority of the deletion delta is from the .sol and bindings, I think it also makes it simpler to explain and being able to verbally distinguish between "staking manager" and "validator manager' without the "validator manager" term being overloaded.

[cam-schultz]

verbally distinguish between "staking manager" and "validator manager"

To solidify that, I renamed PoSValidatorManager to StakingManager. Not only does that emphasize the separation from ValidatorManager, it emphasizes the relationship between it and ERC20TokenStakingManager/NativeTokenStakingManager.

[iansuvak]

This is actually a comment in my draft that I can drop now from the main separation PR. I was happy to wait until the big one is merged to suggest it but I agree that now is as good a time as any!

It's also more accurate since it no longer handles validator state updates just stake related ones.

[bernard-avalabs]

Generally makes sense to me.