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>

beacon_node/store/src/impls.rs

@@ -1,15 +1 @@
-use crate::*;
-use ssz::Encode;
-
 pub mod beacon_state;
-
-/// Prepare a signed beacon block for storage in the database.
-#[must_use]
-pub fn beacon_block_as_kv_store_op<T: EthSpec>(
-    key: &Hash256,
-    block: &SignedBeaconBlock<T>,
-) -> KeyValueStoreOp {
-    // FIXME(altair): re-add block write/overhead metrics, or remove them
-    let db_key = get_key_for_col(DBColumn::BeaconBlock.into(), key.as_bytes());
-    KeyValueStoreOp::PutKeyValue(db_key, block.as_ssz_bytes())
-}