Implement checkpoint sync (#2244)

## Issue Addressed

Closes #1891
Closes #1784

## Proposed Changes

Implement checkpoint sync for Lighthouse, enabling it to start from a weak subjectivity checkpoint.

## Additional Info

- [x] Return unavailable status for out-of-range blocks requested by peers (#2561)
- [x] Implement sync daemon for fetching historical blocks (#2561)
- [x] Verify chain hashes (either in `historical_blocks.rs` or the calling module)
- [x] Consistency check for initial block + state
- [x] Fetch the initial state and block from a beacon node HTTP endpoint
- [x] Don't crash fetching beacon states by slot from the API
- [x] Background service for state reconstruction, triggered by CLI flag or API call.

Considered out of scope for this PR:

- Drop the requirement to provide the `--checkpoint-block` (this would require some pretty heavy refactoring of block verification)


Co-authored-by: Diva M <divma@protonmail.com>

lighthouse/tests/beacon_node.rs

@@ -689,6 +689,19 @@ fn compact_db_flag() {
         .run()
         .with_config(|config| assert!(config.store.compact_on_init));
 }
+#[test]
+fn reconstruct_historic_states_flag() {
+    CommandLineTest::new()
+        .flag("reconstruct-historic-states", None)
+        .run()
+        .with_config(|config| assert!(config.chain.reconstruct_historic_states));
+}
+#[test]
+fn no_reconstruct_historic_states_flag() {
+    CommandLineTest::new()
+        .run()
+        .with_config(|config| assert!(!config.chain.reconstruct_historic_states));
+}
 
 // Tests for Slasher flags.
 #[test]