miscelaneous fixes on syncing, rpc and responding to peer's sync related requests (#3827)

- there was a bug in responding range blob requests where we would incorrectly label the first slot of an epoch as a non-skipped slot if it were skipped. this bug did not exist in the code for responding to block range request because the logic error was mitigated by defensive coding elsewhere
- there was a bug where a block received during range sync without a corresponding blob (and vice versa) was incorrectly interpreted as a stream termination
- RPC size limit fixes.
- Our blob cache was dead locking so I removed use of it for now.
- Because of our change in finalized sync batch size from 2 to 1 and our transition to using exact epoch boundaries for batches (rather than one slot past the epoch boundary), we need to sync finalized sync to 2 epochs + 1 slot past our peer's finalized slot in order to finalize the chain locally.
- use fork context bytes in rpc methods on both the server and client side

beacon_node/network/src/sync/range_sync/chain.rs

@@ -137,10 +137,16 @@ impl<T: BeaconChainTypes> SyncingChain<T> {
 
         let id = SyncingChain::<T>::id(&target_head_root, &target_head_slot);
 
+        let target_slot = if is_finalized_segment {
+            target_head_slot + (2 * T::EthSpec::slots_per_epoch()) + 1
+        } else {
+            target_head_slot
+        };
+
         SyncingChain {
             id,
             start_epoch,
-            target_head_slot,
+            target_head_slot: target_slot,
             target_head_root,
             batches: BTreeMap::new(),
             peers,