Remove double-locking deadlock from HTTP API (#4687)

## Issue Addressed

Fix a deadlock introduced in #4236 which was caught during the v4.4.0 release testing cycle (with thanks to @paulhauner and `gdb`).

## Proposed Changes

Avoid re-locking the fork choice read lock when querying a state by root in the HTTP API. This avoids a deadlock due to the lock already being held.

## Additional Info

The [RwLock docs](https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html#method.read) explicitly advise against re-locking:

> Note that attempts to recursively acquire a read lock on a RwLock when the current thread already holds one may result in a deadlock.

Author: michaelsproul

beacon_node/http_api/src/state_id.rs

@@ -89,9 +89,7 @@ impl StateId {
                     } else {
                         // This block is either old and finalized, or recent and unfinalized, so
                         // it's safe to fallback to the optimistic status of the finalized block.
-                        chain
-                            .canonical_head
-                            .fork_choice_read_lock()
+                        fork_choice
                             .is_optimistic_or_invalid_block(&hot_summary.latest_block_root)
                             .map_err(BeaconChainError::ForkChoiceError)
                             .map_err(warp_utils::reject::beacon_chain_error)?