This commit introduces a new concept called `NotificationService` which
allows Polkadot protocols to communicate with the underlying
notification protocol implementation directly, without routing events
through `NetworkWorker`. This implies that each protocol has its own
service which it uses to communicate with remote peers and that each
`NotificationService` is unique with respect to the underlying
notification protocol, meaning `NotificationService` for the transaction
protocol can only be used to send and receive transaction-related
notifications.

The `NotificationService` concept introduces two additional benefits:
  * allow protocols to start using custom handshakes
  * allow protocols to accept/reject inbound peers

Previously the validation of inbound connections was solely
the responsibility of `ProtocolController`. This caused issues with
light peers and `SyncingEngine` as `ProtocolController` would accept
more peers than `SyncingEngine` could accept which caused peers to have
differing views of their own states. `SyncingEngine` would reject excess
peers but these rejections were not properly communicated to those peers
causing them to assume that they were accepted.

With `NotificationService`, the local handshake is not sent to remote
peer if peer is rejected which allows it to detect that it was rejected.

This commit also deprecates the use of `NetworkEventStream` for all
notification-related events and going forward only DHT events are
provided through `NetworkEventStream`. If protocols wish to follow
each other's events, they must introduce additional abtractions, as is
done for GRANDPA and transactions protocols by following the syncing
protocol through `SyncEventStream`.

Fixes #512
Fixes #514
Fixes #515
Fixes #554
Fixes #556

Co-authored-by: Dmitry Markin <[email protected]>

…etwork-event-system

Co-authored-by: Alexandru Vasile <[email protected]>

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

GRANDPA and transactions follow syncing protocol for peers while they're
still required to validate inbound peers. Peer might be accepted over
GRANDPA and after `ProtocolController` has accepted the peer, the peer
is sent to the protocol for validation. While it was being validated,
syncing protocol may have disconnected from the peer, instructing
GRANDPA to disconnect as well.

If the validation result from GRANDPA is not processed before the
disconnection request is received from

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system

…etwork-event-system