Handle PeerClient timeouts correctly.

[hdevalence]

The current peer handling code from #17 does not handle client request timeouts correctly (or at all). This must be fixed. Because we need to statefully translate the legacy protocol into our internal protocol, I think we cannot use the tower_timeout middleware, because we need to reset the PeerServer state when the request is dropped.

There are three ways we could proceed:

1. "Drop": after a fixed timeout period, if a response has not arrived, fail the peer server and client together, and possibly spin up a new connection to the same remote in a later round of service discovery. This avoids having to change the server's state machine.

2. "Server Timeout": add a timeout event to the server's state machine that fails a client request after a particular time interval (presumably a configured value set by the PeerConnector).

3. "Something with Tower": come up with a way to make the server event loop work gracefully with tower_timeout middleware (e.g., detect that the request has been dropped? unsure how this would trigger an event... or if this option is possible).

[hdevalence]

This is potentially related to #49 in that we need to have some kind of timeout for ping messages, so if we thread the ping messages through the request mechanism, we need to use request timeouts to tear down the server task.

[hdevalence]

Previously I was inclined towards 1) but I think 2) may be better....?

[hdevalence]

If we try 2) then this depends on #53 to have a config field.

[hdevalence]

Paused this to work on #62, resuming.

[hdevalence]

This was done by #65