fix datagram support detection

[KevinZonda]

• treat zero MaxDatagramFrameSize as unsupported.
• avoid send corresponding transport parameters when support is disabled
• report error when calling Send/ReceiveMessage and support is disabled

Fixes #3505.

[TNQOYxNU]

This replace #3507

[marten-seemann]

It seems like the datagramQueue should be initialized when we receive the peer's transport parameters, not on setup, right?

[codecov]

Codecov Report

Base: 85.69% // Head: 85.60% // Decreases project coverage by -0.09% ⚠️

Coverage data is based on head (166d932) compared to base (8c0c481).
Patch coverage: 14.29% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3511      +/-   ##
==========================================
- Coverage   85.69%   85.60%   -0.09%     
==========================================
  Files         136      137       +1     
  Lines        9992    10008      +16     
==========================================
+ Hits         8562     8567       +5     
- Misses       1052     1064      +12     
+ Partials      378      377       -1     

Impacted Files	Coverage Δ
connection.go	77.64% <14.29%> (-0.02%)	⬇️
closed_conn.go	64.71% <0.00%> (-14.71%)	⬇️
packet_handler_map.go	72.37% <0.00%> (-1.73%)	⬇️
http3/server.go	74.29% <0.00%> (-0.23%)	⬇️
internal/ackhandler/ackhandler.go	0.00% <0.00%> (ø)
internal/handshake/token_generator.go	76.60% <0.00%> (ø)
internal/ackhandler/sent_packet_handler.go	78.01% <0.00%> (ø)
zero_rtt_queue.go	57.14% <0.00%> (ø)
conn_id_generator.go	89.66% <0.00%> (+0.37%)	⬆️
... and 1 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[TNQOYxNU]

It seems like the datagramQueue should be initialized when we receive the peer's transport parameters, not on setup, right?

I'm neither familiar with code base nor with standard, so this PR doesn't address this problem, only add a nil check to avoid go panic.
To support "unidirectional datagram", it need to be initiated somewhere, initiate it on demand after peer's transport parameter is the best option.
Another option is always initiate it on setup regardless configuration, straightforward but may have some overhead.
We'd better also disable Send/ReceiveMessage on demand, improve doc, even redesign ConnectionState API to avoid confusion--it's two independent unidirectional channel.

[TNQOYxNU]

Initiate datagramQueue after transport parameter (connection.applyTransportParameters()) not works, seems newPacketPacker need datagramQueue before transport parameter available?
Always initiate it in connection.preSetup() passed all test cases.

[marten-seemann]

Always initiate it in connection.preSetup() passed all test cases.

Sounds good to me. Then we can send datagrams, even if we don't support receiving datagrams. Can you update the PR?