Slight improvement; move our new lists from struct domain to struct protosw (still not really what mjg suggested). This simplifies a lot of it as we're now really only tracking the specific protosw that need action, and it removes all branching directly from pg{slow,fast}timo as we take advantage of the net epoch to remove unloaded protocols.

Tested only lightly with kldload pfsync; kldunload pfsync; which triggers the new bits (but doesn't have any fasttimo/slowtimo callbacks).

Remove from lists prior to the callback

Push additions to the fasttimo/slowtimo list at register time back under the dom_mtx. I note that the fasttimo/slowtimo callouts can race here and invoke the callbacks before we initialize the newly-registered protocol (protosw_init), but this is not new -- the in-tree variant has the same problem, just on a probably-harder-to-hit scale since it iterates over all protocols in all domains.

There's also a window where we can be invoking callbacks and a dynamic protocol is deregistered in the process. I haven't completely thought about how this plays out, but my initial impression is that this is probably relatively harmless. If it gets removed as we're invoking the callback, that's fine -- we don't complete de-orbit of the protocol until the epoch has elapsed, presumably the callouts in the worst case here may terminate a little early during one invocation as the next member has been cleared so we can't observe the rest of the list.

Defer the setting of pr->pr_protocol at deorbit time until the end, and throw an atomic_thread_fence_rel() before it. It seems generally OK to do this locklessly, as long as the other stores have all completed before pf_proto_register() observes the entry as a PR_SPACER as it will immediately bcopy() into the spacer.

pf_proto_register could fail if there's a deregistration in process that would otherwise be freeing up the spacer, but hasn't yet because it's waiting on the epoch. This seems OK.