Remove SIGPIPE handler (#2558)

## Proposed Changes

Remove the SIGPIPE handler added in #2486.

We saw some of the testnet nodes running under `systemd` being stopped due to `journald` restarts. The systemd docs state:

> If systemd-journald.service is stopped, the stream connections associated with all services are terminated. Further writes to those streams by the service will result in EPIPE errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error ignore such errors. If the SIGPIPE UNIX signal handler is not blocked or turned off, such write attempts will also result in such process signals being generated, see signal(7).

From https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html

## Additional Info

It turned out that the issue described in #2114 was due to `tee`'s behaviour rather than Lighthouse's, so the SIGPIPE handler isn't required for any current use case. An alternative to disabling it all together would be to exit with a non-zero code so that systemd knows to restart the process, but it seems more desirable to tolerate journald glitches than to restart frequently.

Author: michaelsproul

lighthouse/environment/src/lib.rs

@@ -391,15 +391,6 @@ impl<E: EthSpec> Environment<E> {
                 Err(e) => error!(self.log, "Could not register SIGHUP handler"; "error" => e),
             }
 
-            // setup for handling a SIGPIPE
-            match signal(SignalKind::pipe()) {
-                Ok(pipe_stream) => {
-                    let pipe = SignalFuture::new(pipe_stream, "Received SIGPIPE");
-                    handles.push(pipe);
-                }
-                Err(e) => error!(self.log, "Could not register SIGPIPE handler"; "error" => e),
-            }
-
             future::select(inner_shutdown, future::select_all(handles.into_iter())).await
         }) {
             future::Either::Left((Ok(reason), _)) => {