Remove `PushPeers` and ignore unsolicited `addr` messages.

PushPeers is more complicated to thread into the rest of our
architecture (we would need to establish a data path connecting our
service handling inbound requests to the network layer's auto-crawler),
and since we crawl the network automatically anyways, we don't actually
need to accept them in order to get updated address information.

The only possible problem with this approach is that zcashd refuses to
answer multiple address requests from the same connection, ostensibly
for fingerprinting prevention (although it's totally happy to give
exactly the same information, as long as you hang up and reconnect
first, lol).  It's unclear how this will interact with our design -- on
the one hand, it could mean that we don't get new addr information when
we ask, but on the other hand, we may have enough churn in our
connection pool that this isn't a problem anyways.

zebra-network/src/peer/connection.rs

@@ -295,20 +295,6 @@ where
                 .await
                 .map_err(|e| e.into())
                 .map(|()| AwaitingResponse(Handler::GetPeers, tx)),
-            (AwaitingRequest, PushPeers(addrs)) => self
-                .peer_tx
-                .send(Message::Addr(addrs))
-                .await
-                .map_err(|e| e.into())
-                .map(|()| {
-                    // PushPeers does not have a response, so we return OK as
-                    // soon as we send the request. Sending through a oneshot
-                    // can only fail if the rx end is dropped before calling
-                    // send, which we can safely ignore (the request future was
-                    // cancelled).
-                    let _ = tx.send(Ok(Response::Ok));
-                    AwaitingRequest
-                }),
             (AwaitingRequest, Ping(nonce)) => self
                 .peer_tx
                 .send(Message::Ping(nonce))
@@ -377,7 +363,10 @@ where
         // Interpret `msg` as a request from the remote peer to our node,
         // and try to construct an appropriate request object.
         let req = match msg {
-            Message::Addr(addrs) => Some(Request::PushPeers(addrs)),
+            Message::Addr(_) => {
+                debug!("ignoring unsolicited addr message");
+                None
+            }
             Message::GetAddr => Some(Request::Peers),
             _ => {
                 debug!("unhandled message type");

zebra-network/src/protocol/internal/request.rs

@@ -1,6 +1,5 @@
 use std::collections::HashSet;
 
-use crate::meta_addr::MetaAddr;
 use zebra_chain::block::BlockHeaderHash;
 
 use super::super::types::Nonce;
@@ -10,15 +9,14 @@ use super::super::types::Nonce;
 pub enum Request {
     /// Requests additional peers from the server.
     Peers,
-    /// Advertises peers to the remote server.
-    // XXX potentially remove this -- we don't use it?
-    PushPeers(Vec<MetaAddr>),
+
     /// Heartbeats triggered on peer connection start.
     ///
     /// This is included as a bit of a hack, it should only be used
     /// internally for connection management. You should not expect to
     /// be firing or handling `Ping` requests or `Pong` responses.
     Ping(Nonce),
+
     /// Request block data by block hashes.
     ///
     /// This uses a `HashSet` rather than a `Vec` for two reasons. First, it

zebra-network/src/protocol/internal/response.rs

@@ -10,10 +10,13 @@ use crate::meta_addr::MetaAddr;
 pub enum Response {
     /// Generic success.
     Ok,
+
     /// Generic error.
     Error,
+
     /// A list of peers, used to respond to `GetPeers`.
     Peers(Vec<MetaAddr>),
+
     /// A list of blocks.
     Blocks(Vec<Block>),
 }