Only activate validator sessions on `register_validators`

[mempirate]

Context

There is currently a stateful "session" requirement between a bolt-sidecar instance, and the validator keys it starts up with. This means that for the duration of the sidecar runtime, validators MUST NOT be moved to other beacon nodes, because they could risk a safety fault. The statefulness works as follows:

• Commitments are made for a certain validator at a certain slot
• The sidecar simulates them, turns them into constraints, and stores them locally
• When that same proposer calls get_header, the proofs are verified against the local constraints

It's clear that IF a validator with active commitments moves to another sidecar after making a commitment, that sidecar will not be aware of the constraints and may risk proposing a faulty block.

There will always be a required session for the duration of the period between making a commitment for a certain slot $N$, and actually proposing slot $N$ (not just a required session but also required uptime, see #673). But after that, validators can theoretically switch around, as long as the sidecar can be made aware of that. The way to make the sidecar aware of that is through the validator_registrations that are sent periodically at the start of each epoch. If one of those pubkeys is also a proposer in the lookahead, we start a conceptual "session", which requires the validator to remain connected to that specific sidecar for the duration of the session.

Since #730, the RPC also pings for active validators at the start of each epoch, to "update" the information it got from the registry with more up-to-date information about where each validator is running. It can therefore help with details of validator ranges in the CCCP.

Not sure of how to signal the start of sessions besides just printing a log for each session started. This could perhaps be used by operators to guide their decisions. In any case, this setup would allow the reorganization of VCs, BNs and sidecars once per epoch.

Caution

We currently use an unsafe lookahead of 64. The session should be aware of the lookahead.