DTLS 1.3 configuration and architecture

[theodorsm]

Description

I have made a WIP DTLS 1.3 configuration and architecture.

As suggested by @JoTurk, it implementes a functional options pattern to provide flexibility in the future. A DTLS 1.3 configuration is created with NewConfigVersion13(c Config, opts ...OptionVersion13) (*Config, error) where an option/config can be implemented like this:

func WithOption13(f func(b bool)) OptionVersion13 {
	return func(c *Config) error {
		c.comeConfig = b
		return nil
	}
}
*/

The codebase for DTLS 1.2 and DTLS 1.3 splits off in conn.go with the new handshake13 function and the new handshakeFSM in handshaker_13.go (note that neither reflects DTLS 1.3 logic yet, just a copy/paste). I suggest we split off as much code as possible suffixed with _13 to keep the development of DTLS 1.3 separate from 1.2.

This PR contains a test of enabling DTLS 1.3 and verifies that an error is returned correctly, as we have not yet started to implement DTLS 1.3 flights.

I would appreciate some input from other maintainers on this! @JoTurk, @daenney, @Sean-Der.

Reference issue

Fixes #731

[JoTurk]

I'm just concerned that if we expose a public APIs, it'll be extremely difficult to change or remove it later, just my personal take about the dtls 1.3 suffix, maybe a sub package? what do you think?

[theodorsm]

@JoTurk thanks!

I agree that we should keep the API private until the DTLS 1.3 implementation is ready; we should only make it public as the last thing to do. If that is what you meant by it?

Regarding the sub-package or suffix: It depends. Using a sub-package I am afraid to loose access to some private fields in structs or functions that can be valuable for the implementation. Using a suffix, we can move fast without those problems, but it will be a bit messy file-wise (especially with flights). Will definitely have another look to see what's possible. I think a combination might be a good solution.

[JoTurk]

I agree that we should keep the API private until the DTLS 1.3 implementation is ready; we should only make it public as the last thing to do. If that is what you meant by it?

Yeah this will be a good call, private or sub package, but private will be better, I agree , for example: if we expose NewConfigVersion13 we'll not be able to remove it in the future :(

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 74 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.87%. Comparing base (956d41d) to head (c9ef3f5).

Files with missing lines	Patch %	Lines
flight_13.go	14.28%	36 Missing ⚠️
conn.go	67.27%	16 Missing and 2 partials ⚠️
handshaker_13.go	51.51%	16 Missing ⚠️
flighthandler_13.go	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #738      +/-   ##
==========================================
- Coverage   82.53%   81.87%   -0.67%     
==========================================
  Files         120      123       +3     
  Lines        6802     6929     +127     
==========================================
+ Hits         5614     5673      +59     
- Misses        778      844      +66     
- Partials      410      412       +2     

Flag	Coverage Δ
go	81.87% <50.00%> (-0.67%)	⬇️

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]

The goal here is not to be complete, but to provide a best-effort skeleton with my current understanding of how the DTLS 1.3 implementation would look. It still contains some duplicate code in conn.go (the linter loves to complain about it), which shall be modified when we implement more of the DTLS 1.3 spec (such as the new record layer encoding #755 ).

I still think the _13 suffix is a good way of structuring to move on without large refactorings. This reduces the number of new public APIs (now private) we would need to expose when using a sub-package. I reduced the flight handlers files by grouping them into flighthandlers_client_13 and flighthandlers_server_13. We can always decide to make a sub-package later if we see it necessary.