Add limit for incoming connections from peers without channels

[remyers]

Limit the number of incoming connections from nodes we don't have channels with.

• when an incoming connection comes in, the switchboard checks if we have channels with that peer
• if we have channels with an incoming peer, do not track it
• if an incoming peer is on the sync-whitelist, do not track it
• otherwise, track the connection
• when we reach our configured limit of tracked peers without channels, disconnect the oldest tracked peer
• when a tracked peer disconnects or creates a channel, we will stop tracking that peer

We do not track peers we initiate outgoing channel connections to

[thomash-acinq]

We should think about how this interacts with onion messages. Anyone can connect directly to us to send us a message (to request an invoice for an offer for instance) and we want to keep this behavior. We already have a limit to the number of onion message we accept per second (https://github.com/ACINQ/eclair/blob/master/eclair-core/src/main/scala/fr/acinq/eclair/io/PeerConnection.scala#L182) but unless we are currently receiving a lot of messages, we want to continue accepting messages from strangers. Looking at your proposal, it seems that once we reach the maximum number of connections allowed we don't accept new connections (and thus don't accept onion messages), if it doesn't cause other problems I would prefer continuing accepting new connections but closing old idle ones to stay under the limit.

[remyers]

We should think about how this interacts with onion messages.

Good point; onion messages are going to be a new source of connections from nodes without channels. I didn't see anything in the Onion Message PR about whether or not a connection should be kept open indefinitely after sending an onion message. This could lead to hitting the limit proposed by this PR and cause an unintentional DoS for both opening channels and receiving onion messages. Without any limit it could also lead to an ever increasing number of connections.

As suggested, one approach is to track a timestamp for each connection without a channel and periodically close inactive connections. This would require adding a new data structures in Switchboard, or another dedicated class. I was trying to avoid that, but I'll take a look at what would be needed.

[remyers]

This PR implements similar functionality to LDK PR #1988 wrt limiting incoming connections.

[codecov-commenter]

Codecov Report

Merging #2601 (a00f448) into master (a52a10a) will decrease coverage by 0.05%.
The diff coverage is 95.83%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##           master    #2601      +/-   ##
==========================================
- Coverage   85.69%   85.65%   -0.05%     
==========================================
  Files         211      212       +1     
  Lines       16919    16962      +43     
  Branches      728      723       -5     
==========================================
+ Hits        14499    14529      +30     
- Misses       2420     2433      +13     

Impacted Files	Coverage Δ
...-core/src/main/scala/fr/acinq/eclair/io/Peer.scala	87.89% <90.00%> (-0.08%)	⬇️
...r/acinq/eclair/io/IncomingConnectionsTracker.scala	94.73% <94.73%> (ø)
...r-core/src/main/scala/fr/acinq/eclair/Eclair.scala	56.43% <100.00%> (ø)
...re/src/main/scala/fr/acinq/eclair/NodeParams.scala	93.68% <100.00%> (+0.04%)	⬆️
...src/main/scala/fr/acinq/eclair/io/Monitoring.scala	100.00% <100.00%> (ø)
...main/scala/fr/acinq/eclair/io/PeerConnection.scala	86.90% <100.00%> (+0.09%)	⬆️
...rc/main/scala/fr/acinq/eclair/io/Switchboard.scala	85.71% <100.00%> (+1.40%)	⬆️
...cinq/eclair/remote/EclairInternalsSerializer.scala	97.77% <100.00%> (ø)

... and 12 files with indirect coverage changes

[t-bast]

Concept ACK! We'll probably need to beef up the release notes with more details about DoS issues at various level, I believe this should help node operators configure their eclair node to make sure this new feature doesn't create more problems that it solves.

[t-bast]

LGTM, I only have nits and we should be good to go 👍

[t-bast]

LGTM 🚀