Switch goroutines for contexts in packetconn

[noboruma]

Remove goroutines in Write/Read hot paths from packetconn

[codecov]

Codecov Report

❌ Patch coverage is 79.41176% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.38%. Comparing base (65248b8) to head (6f42564).

Files with missing lines	Patch %	Lines
netctx/packetconn.go	79.41%	4 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #395      +/-   ##
==========================================
- Coverage   84.45%   84.38%   -0.07%     
==========================================
  Files          41       41              
  Lines        3416     3388      -28     
==========================================
- Hits         2885     2859      -26     
  Misses        393      393              
+ Partials      138      136       -2     

Flag	Coverage Δ
go	84.38% <79.41%> (-0.07%)	⬇️

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

☔ View full report in Codecov by Harness.
📢 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.

[JoTurk]

Looks great thank you, I also tested it locally :)

Just 2 comments and one nit.

[JoTurk]

nit: maybe we shouldn't ignore deadline errors?

[noboruma]

So actually I gave that one some thoughts because it was specifically handled in the previous impl. My conclusion here is that failing at the SetReadDeadline stage should only happen if the connection is closed already. So we don't really care at that stage. Now this holds true for standard implementations, in the case the connection was not closed and the SetReadDeadline truly failed (which in theory should never happen unless the underlying implementation is buggy) we would be in much more trouble since that operation could hang forever (which was also the case in the previous impl since we only returned the err after the read finished).

I think a better alternative here would be to simply panic in case of error so it gives a chance to recover?

[noboruma]

Actually realized we cannot do that properly because AfterFunc would panic on a different goroutine - reworking the whole SetReadDeadline instead

[noboruma]

Here I am opting for a closure of the whole connection so that we avoid hanging