Remove TCP option alignment padding

[rscheff]

Summary

As TCP SYN option space is scarce, padding each option
individually for a 32bit alignment seems wasteful.

This is currently a placeholder, to be extended when
the AccECN option with variable length is added.

[rrs]

Why are you removing the NOP Pad chunks? IP options *must* be a multiple of 4 which is what the pad does, taking
it out is going to make the options incorrect I would think??

[rscheff]

The overall TCP option space needs to be 4 octet align (which I believe is still in the code, as there should be a block after this to stuff in final EOL / NOPs; see line 1857/1832ff)

Each individual option isn't strictly required to be 4 octet aligned - I believe that was a legacy optimization for a "fast path" pass for parsing options quickly, but TCP required all stacks to be able to process options byte-by-byte also. As long as I can remember, FBSD was going byte-oriented through the TCP option space - there never existed the 4-byte aligned fast path to begin with - in our stack at least.

The problem really arises by stacking various (and potentially variable length) options and aligning each to 4 bytes; this may burn multiple times 1..3 NOP bytes, which could be used by a variable length option such as AccECN to provide another field (or allow AccECN / MPTCP options to exist at all).

[tuexen]

Let us discuss this on the bi-weekly transport call... I'm not convinced that the gain you get from this is higher than the risk to run into bugs on peer implementations.

[rscheff]

Certainly; as currently this doesn't have a ready-to-go use case, this Diff is not intended for immediate commit. Also, this change could certainly be dependent on the (negotiated) features of the TCP session (e.g. MPTCP, AccECN, AO, ...) once these other features become available/ready.

[rscheff]

Discussed in @transport call, abandoning as no immediate need, and high liklihood to break LRO and no gain. Also, the options should be stacked in such a way to minimize NOPs already.