Add flag to disable lock timeouts (#2714)

## Issue Addressed

Mitigates #1096

## Proposed Changes

Add a flag to the beacon node called `--disable-lock-timeouts` which allows opting out of lock timeouts.

The lock timeouts serve a dual purpose:

1. They prevent any single operation from hogging the lock for too long. When a timeout occurs it logs a nasty error which indicates that there's suboptimal lock use occurring, which we can then act on.
2. They allow deadlock detection. We're fairly sure there are no deadlocks left in Lighthouse anymore but the timeout locks offer a safeguard against that.

However, timeouts on locks are not without downsides:

They allow for the possibility of livelock, particularly on slower hardware. If lock timeouts keep failing spuriously the node can be prevented from making any progress, even if it would be able to make progress slowly without the timeout. One particularly concerning scenario which could occur would be if a DoS attack succeeded in slowing block signature verification times across the network, and all Lighthouse nodes got livelocked because they timed out repeatedly. This could also occur on just a subset of nodes (e.g. dual core VPSs or Raspberri Pis).

By making the behaviour runtime configurable this PR allows us to choose the behaviour we want depending on circumstance. I suspect that long term we could make the timeout-free approach the default (#2381 moves in this direction) and just enable the timeouts on our testnet nodes for debugging purposes. This PR conservatively leaves the default as-is so we can gain some more experience before switching the default.

beacon_node/src/cli.rs

@@ -568,4 +568,12 @@ pub fn cli_app<'a, 'b>() -> App<'a, 'b> {
                 .value_name("PATH")
                 .takes_value(true)
         )
+        .arg(
+            Arg::with_name("disable-lock-timeouts")
+                .long("disable-lock-timeouts")
+                .help("Disable the timeouts applied to some internal locks by default. This can \
+                       lead to less spurious failures on slow hardware but is considered \
+                       experimental as it may obscure performance issues.")
+                .takes_value(false)
+        )
 }

beacon_node/src/config.rs

@@ -504,6 +504,10 @@ pub fn get_config<E: EthSpec>(
             .extend_from_slice(&pubkeys);
     }
 
+    if cli_args.is_present("disable-lock-timeouts") {
+        client_config.chain.enable_lock_timeouts = false;
+    }
+
     Ok(client_config)
 }
 

beacon_node/src/lib.rs

@@ -8,6 +8,7 @@ pub use beacon_chain;
 use beacon_chain::store::LevelDB;
 use beacon_chain::{
     builder::Witness, eth1_chain::CachingEth1Backend, slot_clock::SystemTimeSlotClock,
+    TimeoutRwLock,
 };
 use clap::ArgMatches;
 pub use cli::cli_app;
@@ -66,6 +67,11 @@ impl<E: EthSpec> ProductionBeaconNode<E> {
         let freezer_db_path = client_config.create_freezer_db_path()?;
         let executor = context.executor.clone();
 
+        if !client_config.chain.enable_lock_timeouts {
+            info!(log, "Disabling lock timeouts globally");
+            TimeoutRwLock::disable_timeouts()
+        }
+
         let builder = ClientBuilder::new(context.eth_spec_instance.clone())
             .runtime_context(context)
             .chain_spec(spec)