Accept only --in-peers many inbound full nodes in SyncingEngine (#14603)

* Accept only `--in-peers` many inbound full nodes in `SyncingEngine`

Due to full and light nodes being stored in the same set, it's possible
that `SyncingEngine` accepts more than `--in-peers` many inbound full
nodes which leaves some of its outbound slots unoccupied.

`ProtocolController` still tries to occupy these slots by opening
outbound substreams. As these substreams are accepted by the remote peer,
the connection is relayed to `SyncingEngine` which rejects the node
because it's already full. This in turn results in the substream being
inactive and the peer getting evicted.

Fixing this properly would require relocating the light peer slot
allocation away from `ProtocolController` or alternatively moving entire
the substream validation there, both of which are epic refactorings and
not necessarily in line with other goals. As a temporary measure, verify
in `SyncingEngine` that it doesn't accept more than the specified amount
of inbound full peers.

* Fix tests

* Apply review comments

substrate/client/network/src/protocol/notifications/behaviour.rs

@@ -319,6 +319,8 @@ pub enum NotificationsOut {
 		received_handshake: Vec<u8>,
 		/// Object that permits sending notifications to the peer.
 		notifications_sink: NotificationsSink,
+		/// Is the connection inbound.
+		inbound: bool,
 	},
 
 	/// The [`NotificationsSink`] object used to send notifications with the given peer must be
@@ -1810,6 +1812,7 @@ impl NetworkBehaviour for Notifications {
 				negotiated_fallback,
 				received_handshake,
 				notifications_sink,
+				inbound,
 				..
 			} => {
 				let set_id = crate::peerset::SetId::from(protocol_index);
@@ -1834,6 +1837,7 @@ impl NetworkBehaviour for Notifications {
 								let event = NotificationsOut::CustomProtocolOpen {
 									peer_id,
 									set_id,
+									inbound,
 									negotiated_fallback,
 									received_handshake,
 									notifications_sink: notifications_sink.clone(),