addStakeContender() being called from net_processing is not robust because there are various ways a proof may be introduced (via network, RPC, loaded at startup, etc). This results in the cache being unaware of proofs in various scenarios, eventually breaking contender voting. The robust solution is to put peerManager in charge of adding contenders to the cache whenever a proof is successfully registered. This is the first step to achieving that.
This diff only moves the cache with minimal other changes (excepting some locking fixes). The pass-through API of the cache in peermanager is not ideal, however some of these can be refactored away in future diffs to reduce future maintenance overhead.
There is no change in behavior.