Modularize some IPv4/IPv6 protocol code

[jtl]

Summary

We currently statically compile in support for a number of protocols. We can make much of this more modular. This will allow users to compile code for the things they want to use and exclude support for things they don't want to use. Additionally, this will allow users to more cleanly insert custom modules to handle some of these protocols.

This changeset includes these logical changes:

• Start conditionally compiling the ip_encaps code based on the protocols that need it. Even if none of the protocols need it, make a config option ENCAPS to compile the support so it is available for modules. Add the ENCAPS option to all existing kernel configurations to keep the current functionality.
• Setup an encapsulation-level mechanism for registering protocols that will use the encapsulation code.
• Switch all current users of the encapsulation interface to registering protocols with the encapsulation code, rather than relying on the current static encapsulated-protocol configuration.
• Add an RSVP_SUPPORT option and make the RSVP support code conditioned on either the RSVP_SUPPORT or MROUTING options. This allows modules to use the RSVP infrastructure even if MROUTING is not compiled, but allows users to drop RSVP support code if they don't need it. Add the RSVP_SUPPORT option to all existing kernel configurations to keep the current functionality.
• Allow the IPv6 destination options extension header code and routing options extension header code to be compiled as modules. Add configuration options ROUTE6 and DEST6 to cause the code to be statically compiled in the kernel. Add the new ROUTE6 and DEST6 options to all existing kernel configurations to keep the current functionality.

NOTE: It is my plan to defer committing this code until after stable/14 has branched.

[melifaro]

I love the part of this diff that creates the modular encap KPI, that's really awesome and I love to see this in base.
What I'm not sure about is the creation of compile-in options. I'm not sure I completely understand the rationale here. Flexibility is good, but I guess people compile out certain functionality either to save space or to address security concerns (or both). It would be nice to add more datapoints in that regard (for example, "disabling feature X gives Y kilobytes on amd64 kernel" or "feature X can be seen as unsecure b/c .." and there is no good/simple way to disabling it in the runtime other that compiling out). It also comes up with the maintenance cost attached - ifdefs, build system conditionals and more code variation to test.
On the implementation side, number of people use custom kernel configs. Landing these changes will make them automatically build kernels without IPv6 extensions and other encaps. This silent feature disappearing worries me, actually.

sys/netinet/ip_encap.c

385

Nit: probably worth using error, which is more commonly used to save/propagate errno?

390

ipproto_register() may return EEXIST if the proto is already registered. Is the desired behaviour here to just increase usage count? Maybe it's worth asserting here to indicate that this should not happen and the caller code needs to be updated?

420

Given the mutex is only use to guard addition/deletion to the encapsulated arrays (which should be rate), maybe it's worth to have a single mutex for both families?

sys/riscv/conf/GENERIC

34

I'd suggest renaming it to something like INET6_ROUTEHDR or something similar. Just ROUTE6 is too ambiguous.

35

Similarly, something like INET6_DESTHDR can be a more descriptive name.