Avoid dropping packets immediately in mux

[lactyy]

Description

As discussed in this thread on the Gophers Slack, internal/mux needs a pending queue for packets that would dropped in some situations. (e.g. ICE transport blocks until it is in a connected state, losing any DTLS packets received in the meantime)

Sorry, I accidentally closed the issue before. I've reopened an issue with fixes.

Reference issue

N/A

[codecov]

Codecov Report

Attention: Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.

Project coverage is 65.06%. Comparing base (f29ef99) to head (cef9fd4).

Files	Patch %	Lines
internal/mux/mux.go	80.95%	3 Missing and 1 partial ⚠️

❗ There is a different number of reports uploaded between BASE (f29ef99) and HEAD (cef9fd4). Click for more details.

HEAD has 2 uploads less than BASE

Flag	BASE (f29ef99)	HEAD (cef9fd4)
go	2	0

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #2814       +/-   ##
===========================================
- Coverage   78.92%   65.06%   -13.87%     
===========================================
  Files          89       67       -22     
  Lines        8317     3237     -5080     
===========================================
- Hits         6564     2106     -4458     
+ Misses       1276     1005      -271     
+ Partials      477      126      -351     

Flag	Coverage Δ
go	?
wasm	65.06% <80.95%> (+0.17%)	⬆️

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.

[Sean-Der]

Thank you @lactyy! Great to see this finally fixed.

What do you think of spawning goroutine only if something needs to go in the pending queue? When the queue is drained the routine exits

Otherwise each PeerConnection gets another goroutine that will mostly go unused. I have users report doing 10k+ on a machine, so I worry what the impact will be.

Would it be possible to add a unit test also? You could spin up some fake dispatch and confirm that it gets the packet eventually.

[lactyy]

Hello, @Sean-Der! Sorry for the late response, was this okay? I changed some of the code and added a unit test.

[Sean-Der]

Hey @lactyy mind trying this again now that it is merged!

I instead process the queue w/e a new dispatch is added. I set a limit of 15 packets (but we can raise it!)

[lactyy]

Hello @Sean-Der, I can confirm this has been fixed in the latest commit. thank you!

[Sean-Der]

Thank you for opening the PR @lactyy! I am sure that bothered lots of people, but they never put the time in to help out :)