Replace networking stack with etcd-based approach

[noonio]

Why

We saw in the recent spike #1591 that Raft (via etcd) provides benefits over our present approach: it allows for more instability in the client connections, and more transparency in what is happening.

We would like a resiliant and reliable networking layer, and this seems like a viable approach.

What

• Use learnings from the spike to integrate raft via etcd
• Rely on the etcd cluster binary
  • Do not use the etcdctl binary to send client requests; use a Haskell (client) library instead
• The PR Example of the simple dropout example on-top of the raft branch #1786 must run successfully on top of this work (note that it worked on the Spike, and fails on present master)
• An ADR is created to supersede previous decisions and document the current path (relevant: https://hydra.family/head-protocol/adr/6, https://hydra.family/head-protocol/adr/17, and https://hydra.family/head-protocol/adr/27)
• The (updated) network stack is documented in https://hydra.family/head-protocol/docs/dev/architecture/networking

How

• Write/update ADRs Write an ADR about network properties and etcd #1852
• Rebase raft-network branch
• Rebase Example of the simple dropout example on-top of the raft branch #1786 scenario
• Implement an equivalent of PeerConnected
  • Update this to use grapesy and handle minority responses for Disconnected
  • Bring back per-peer connectivity using leases?
• Implement an equivalent of VersionMismatch
  • Update this using a version kv and transactions
• Replace etcdctl client with the grapesy grpc client, see Create grapesy-etcd library #1843
  • Alternative: use etcd HTTP API
• Remove superseded Hydra.Node.Network, Hydra.Network.Ouroboros and Hydra.Network.Reliability modules
  • Also clean up and remove not needed things (e.g. NodeId from Connected)
• Fix static binary compilation (new lib snappy)
• Document how the Etcd component works (and maps things to etcd domain)