Light client server support [tracking issue]

[michaelsproul]

Description

We should support the full node side of the light client protocol.

The components we need for this are:

Groundwork

• Light client types in consensus/types. This includes LightClientBootstrap, LightClientUpdate and all the other types defined here.
• Ability to construct merkle proofs for the state.finalized_checkpoint.root, state.current_sync_committee and state.next_sync_committee.
• CLI flags to enable / disable the light client server ([Merged by Bors] - Add --light-client-server flag and state cache utils #3714)
• Produce and cache light client data in the BeaconChain to support fast gossip validation and RPC processing #4926
• Add Capella & Deneb light client support #4896
• Add SSZ tests for the LightClient* types we support #4897

P2P (Gossip & ReqResp)

• Support the new gossip topics defined in the P2P spec
  • [Merged by Bors] - Adding light_client gossip topics #3693
• Support the new network RPCs defined in the P2P spec
  • Light client updates by range rpc and add LightClientHeader #3886
  • Support LightClientFinalityUpdate and LightClientOptimisticUpdate rpcs #3849
  • [Merged by Bors] - Added LightClientBootstrap V1  #3711

REST APIs

• API for LightClientBootstrap, LightClientFinalityUpdate, LightClientOptimisticUpdate and light client events #3954
• Add beacon API support for light client updates by range #4895

Optimization

• Optimise light client bootstrap and range
  • Persist light client updates #5545
  • Persist light client bootstrap #5915

Production: enabling Light Client server by default

• Add tests for Light Client ReqResp interfaces #4940
• Measure performance impact and additional resource requirement
• Review inbound request quota config
• Evaluate whether changes to peer count / inbound peer ratio is required
• Enable light client server by default

Additional Details

• Constructing merkle proofs: I think it will be easiest if we pursue a non-generic approach for this initially, as a generic approach would require digging into the guts of tree_hash_derive to add methods for generating merkle proofs based on field indices. We probably want that eventually, but a non-generic approach can inform the generic implementation. If we implement this atop unstable we probably want to integrate with the BeaconTreeHashCache so that we don't need to re-hash the whole state for the intermediate nodes of the proof. Alternatively we could implement it without caching and rely on the arrival of tree-states to improve performance (because caching is then built in to each field's tree_hash_root() method).
• NOTE: in-memory tree states is now on stable as of v5.2.0.

[michaelsproul]

I think we can start merging PRs for these features roughly in order, starting with the types

cc @Giulio2002 @pawanjay176