Bind relay connections to the relay address for TCP allocations

[rg0now]

This is a humble attempt to fix #512

The trick is to use the proper sockopts to create the TCP relay listener and the relay connections (SO_REUSEADDR and wherever needed, SO_REUSEPORT).

Caveats:

• We import a battle-tested external module to hide the OS-dependent "reuseport" sockopts. Let me know if adding new imports is discouraged, we can easily reproduce the required functionality for the GOARCHs supported by pion (which would be those?).
• RelayGenerator.AllocateConn is back for generating the outbound TCP relay connections, so no more hardcoded net.DialTCP in the server. I think this is for the better: now we can abstract away all network-related functions the server invokes (e.g., to wrap OTel telemetry on top of TCP connections). This sort of fixes the API worries I mentioned in an earlier thread.
• Unfortunately ATM we cannot abstract the TCP listener creation in RelayGenerator.AllocateListener via pion/transport. The reason is that transport.Net does not (yet?) support net.ListenerConfig, which we would need to enforce the reuseport semantics. Note that both AllocateListener and AllocateConn must enforce reuseport, otherwise either of them will fail with "Address already in use". Currently we hard-code the net.ListenerConfig in AllocateListener instead of going through transport.Net, which is on the one hand ugly and on the other hand requires adding an even uglier context.TODO() in Listen. We can easily implement something like CreateListenerConfig in transport.Net (just like we already have CreateDialer) and hope someone jumps in to implement TCP in pion/transport, let me know if you want be to send a PR.

[Sean-Der]

Damn this is amazing @rg0now thanks for doing this.

I would like to keep the package zero dependency. Maybe put reuse functionality in pion/transport? I have been burned by 3rd parties with Pion a few times :(

We can easily implement something like CreateListenerConfig in transport.Net (just like we already have CreateDialer) and hope someone jumps in to implement TCP in pion/transport, let me know if you want be to send a PR.

Let's do that! You have my blanket support to do w/e is the right thing, I am here to approve/merge quick :)

[codecov]

Codecov Report

❌ Patch coverage is 64.28571% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.90%. Comparing base (d74862d) to head (8a4fba3).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
internal/allocation/allocation_manager.go	73.91%	3 Missing and 3 partials ⚠️
relay_address_generator_none.go	40.00%	6 Missing ⚠️
relay_address_generator_range.go	40.00%	6 Missing ⚠️
server.go	33.33%	2 Missing ⚠️

❌ Your patch status has failed because the patch coverage (64.28%) is below the target coverage (70.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #514      +/-   ##
==========================================
- Coverage   81.35%   80.90%   -0.45%     
==========================================
  Files          46       46              
  Lines        2971     3017      +46     
==========================================
+ Hits         2417     2441      +24     
- Misses        346      364      +18     
- Partials      208      212       +4     

Flag	Coverage Δ
go	80.90% <64.28%> (-0.45%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rg0now]

See pion/transport#372 and pion/transport#373. Please merge and release pion/transport so that I can update this PR.

[rg0now]

Thanks @JoTurk for releasing pion/transport/v4, it did not occur to me how much work this is. Sorry for making you undergo this...

Removed external dependency, restored the servers' TCP relay listener to use VNet, and fixed the StaticIP -> StaticIPs transition in pion/transport. We still indirectly depend on pion/transport/v3 (I guess via pion/stun), we may want to wait until new versions are released or merge this as is and do the version updates later.

[JoTurk]

Thanks @JoTurk for releasing pion/transport/v4, it did not occur to me how much work this is. Sorry for making you undergo this...

npnp, I wanted to do this for months since we started working on pion/SCP and was just waiting for an opportunity :)

[JoTurk]

we may want to wait until new versions are released or merge this as is and do the version updates later.

I think we should merge, we already merged breaking changes to this library.

[Sean-Der]

beautiful!

[Sean-Der]

Merge away @rg0now sorry about the merge conflicts :(

Can I get your take on #464 ?

Getting very close to new release!