fix(relay): enforce per-peer reservation limit at boundary

[failuresmith]

Summary

• change the per-peer reservation guard to reject at the configured boundary
• add a regression test covering two connections that share the same PeerId

Root cause

The relay admission check used > instead of >= when evaluating max_reservations_per_peer, which allowed one extra reservation when a peer was already exactly at the configured limit.

Validation

• cargo fmt --check
• cargo test -p libp2p-relay

[elenaf9]

The test is very much appreciated, thanks!

The test right now creates two clients with the same peer ID, because the client behavior can have only one reservation per connection at a time.
I think we can simplify this quite a lot by instead adding two listen addresses for the relay and have one client try to use both addresses (which internally will then create two connections between client and relay).

[failuresmith]

I like your idea of simplifying this to a single client.

My only concern is that it may not cover exactly the same case. From what I can tell, a second reservation to the same relay is already handled specially, and once there is a direct connection, the client may reuse it rather than open a second one.

Because of that, I wasn’t sure that using two relay listen addresses would reliably give us two simultaneous client-relay connections with the same PeerId, which is the case this regression was meant to cover.

That said, I may be missing something. If this does reliably create two connections while still testing the same boundary condition, I’d be happy to change it.