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

• [x] Light client types in consensus/types. This includes LightClientBootstrap, LightClientUpdate and all the other types defined here.
• [x] Ability to construct merkle proofs for the state.finalized_checkpoint.root, state.current_sync_committee and state.next_sync_committee.
• [x] CLI flags to enable / disable the light client server (#3714)
• [x] #4926
• [x] #4896
• [x] #4897

P2P (Gossip & ReqResp)

• [x] Support the new gossip topics defined in the P2P spec
  • [x] #3693
• [ ] Support the new network RPCs defined in the P2P spec
  • [ ] #3886
  • [x] #3849
  • [x] #3711

REST APIs

• [x] #3954
• [ ] #4895

Optimization

• [ ] Optimise light client bootstrap and range
  • [ ] #5545
  • [ ] #5915

Production: enabling Light Client server by default

• [ ] #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