Inbound DHT middleware

[sdbondi]

Description

This PR adds the vaious inbound DHT middleware components.
The module is currently not part of the module tree as
there are a number of changes to the comms and tari_middleware
crates that need to go along with it.

Overview of middleware architecture

The tari_comms_dht crate adds DHT functionality to tari_comms.
It provides two sets of middleware (inbound and outbound) which
process incoming requests and outgoing messages respectively.

Attaching to comms

In tari_comms, incoming and outgoing messages are connected using two mpsc sender/receiver pairs.
One for incoming messages (receiving InboundMessages) and one for outbound messages (sending OutboundMessages).

The DHT module consists of two middleware layers (as in tower_layer::Layer) which form
an inbound and outbound pipeline for augmenting messages.

Inbound Message Flow

InboundMessages are received from the incoming comms channel (as in the receiver side of
of the mpsc channel which goes into CommsBuilder::new().incoming_message_sink(sender)).
Typically, a ServicePipeline from the tari_comms_middleware crate is used to connect
a stream from comms to the middleware service.

InboundMessage(comms) -> DHT Inbound Middleware -> DhtInboundMessage(domain)

The DHT inbound middleware consist of:

• DeserializeMiddleware deserializes the body of an InboundMessage into a DhtEnvelope.
• DecryptionMiddleware attempts to decrypt the body of a DhtEnvelope if required. The result of that decryption
  (success or failure) is passed to the next service.
• ForwardMiddleware uses the result of the decryption to determine if the message is destined for this node or
  not. If not, the message will be forwarded to the applicable peers using the OutboundRequester (i.e. the outbound
  DHT middleware).
• DhtHandlerMiddleware handles DHT messages, such as Join and Discover. If the messages are not DHT messages
  the next_service is called.

Motivation and Context

Ref #621
Ref #675

How Has This Been Tested?

Middlewares have unit tests although they will only be connected in subsequent PRs

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Feature refactor (No new feature or functional changes, but performance or technical debt improvements)
• New Tests
• Documentation

Checklist:

• I'm merging against the development branch
• I ran cargo-fmt --all before pushing
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• [~] I have added tests to cover my changes.

[CjS77]

LGTM