Investigate methods of reducing code size for Validator Manager contracts

[geoff-vball]

Context and scope
We have been routinely running up against code size limits for validator-manager contracts, with ERC20TokenStakingManager currently only having ~500 bytes of headroom before hitting the cap, and NativeTokenStakingManager having ~1200 bytes of headroom.

This has prevented us from including external getters for state variables, which are necessary to implement proper tooling for the contracts.

Discussion and alternatives
Would externalizing the churn tracker help us save on code size? Externalizing the churn tracker would also help other implementations include it, which would be helpful because it is consensus-critical.

[cam-schultz]

The external library pattern described here seems promising. It has a few advantages: 1) it can be applied piecemeal to individual contracts or even only parts of a contract and 2) contract upgrades function in the same way, since each contract in the class hierarchy still maintains its own storage.

[cam-schultz]

860 - 720 - 550

The external library pattern #675 (comment) seems promising

Early tests of this pattern have been disappointing. So far ~100 lines of code have been migrated into a library on this branch, however, the overall code size of ERC20TokenStakingManager actually increased by 310 bytes. Moreover, the increase so far is linear w.r.t. the number of methods migrated.

[cam-schultz]

Another consideration to "librarification" regardless of the strategy is how to handle calls up or down the class hierarchy. The most straightforward approach seems to be to refactor the implementations to decouple library calls from inter-class calls. It's unclear how much of a lift that would be, as well as if that can be done safely.