Add supported_versions extension feature from DTLS v1.3

[philipch07]

Description

This adds the supported_versions extension feature in accordance with DTLS v1.3 section 5.3. Note that it links to TLS 1.3 section 4.2.1.

Reference issue

Completes #729

[codecov]

Codecov Report

❌ Patch coverage is 80.23256% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.64%. Comparing base (120a895) to head (f6b0286).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/protocol/extension/supported_versions.go	80.26%	10 Missing and 5 partials ⚠️
pkg/protocol/extension/extension.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #730      +/-   ##
==========================================
+ Coverage   78.59%   78.64%   +0.04%     
==========================================
  Files         101      102       +1     
  Lines        6830     6916      +86     
==========================================
+ Hits         5368     5439      +71     
- Misses       1087     1098      +11     
- Partials      375      379       +4     

Flag	Coverage Δ
go	78.66% <80.23%> (+0.04%)	⬆️
wasm	57.46% <80.23%> (+0.31%)	⬆️

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.

[theodorsm]

@philipch07 Thanks for diving into this extension so fast!

Removing the Selected field should simplify this implementation + tests a bit.

Additionally, we should check upon unmarshaling if the parsed major/minor version is supported by us, i.e is it one of version vars defined in version.go. We should discard versions not supported and only append supported versions.

[philipch07]

Additionally, we should check upon unmarshaling if the parsed major/minor version is supported by us, i.e is it one of version vars defined in version.go. We should discard versions not supported and only append supported versions.

For discarding, I think this can cause an unmatched value with marshalling and unmarshalling: for example, lets say the list passed in is:

[VersionX_Y, Version1_3, Version1_2, Version1_0]

Then it would be marshalled (and later unmarshalled) as:

[Version1_3, Version1_2, Version1_0]

Which is no longer the same as the original input. Is that behavior still desirable? I'm not sure if it causes any issues, but it was just something that I noticed.

(Also thanks for reviewing so quickly! I really appreciate the quick feedback!)

[JoTurk]

I think this should be a dumb packs/unpacks bytes and formats.
no "is this version supported", no negotiation, no state. no policy leaking.

and all the handling/decision-making/logic should be in the handshake layer, like other extensions.

[theodorsm]

Would be nice with a test case with some non-existent version values too (ex: 0xef, 0x0d)

[theodorsm]

I added the missing extension type bytes in my commit.

@philipch07, thank you so much for taking on this implementation and being patient with feedback!

This PR LGTM now. @joeturki, @Sean-Der, what do you think?

[JoTurk]

Thank you so much

[JoTurk]

@philipch07 @theodorsm feel free to merge it, if it's ready :)

[philipch07]

Thanks @theodorsm and @joeturki for the feedback, fixing it up, and merging! Sorry I didn't see the messages earlier as I'm currently at work. I'm looking forward to the next tasks!