Richard Levitte

This currently requires the following additional PRs: - #18676 - #18949

This is now ready enough for a real review

~cca82837bd8ea3ddfa56717353b97d22cacf1505~e515875d947a702d5127622cd673fd947352fa6a implements the alignment suggested here: https://github.com/openssl/openssl/pull/18838#discussion_r946802714 Personally, I *thoroughly* dislike this re-alignment. It means that statements end up looking weirdly aligned, all because of a brace at the end...

> > Personally, I _thoroughly_ dislike this re-alignment. It means that statements end up looking weirdly aligned, all because of a brace at the end of a `case` or `default`...

Re case indentation, I really think that should be a separate and broader coding style discussion. It seems unlikely that we will get to an agreement here. Meanwhile, I'm going...

Refactored to avoid the case-and-brace source formatting dispute... I find the result more appealing, now that it's done. A bunch of review comments addressed.

> One thing that seems to be missing is to check the allowed frames based on the packet type. I.e., check against this table: https://github.com/openssl/openssl/blob/5f10b1f371469f6ca921337c4d390f05ada6c606/doc/designs/quic-design/tx-packetiser.md#frames > > In case of...

> > One thing that seems to be missing is to check the allowed frames based on the packet type. I.e., check against this table: https://github.com/openssl/openssl/blob/5f10b1f371469f6ca921337c4d390f05ada6c606/doc/designs/quic-design/tx-packetiser.md#frames > > In case...

> CIs are relevant. This still depends on #18949, so will obviously not be possible to merge before that one's in.

I've rebased, and squashed while I was at it.