pf: also apply dummynet to route-to/dup-to packets

[kp]

Summary

If packets are processed by a route-to/dup-to/reply-to rule (i.e. they
pass through pf_route(6)) dummynet was not applied to them.
This is because pf_route(6) passes packets directly to ifp->if_output(),
so the dummynet functions were never called.

Factor out the dummynet code and call dummynet prior to
ifp->if_output(). This has a secondary benefit of reducing some code
duplication between the IPv4 and IPv6 paths.

Sponsored by: Rubicon Communications, LLC ("Netgate")

[glebius]

The new function is bool, to tell if the packet was consumed. Let's call this modern FreeBSD style. You also pass a pointer to pointer, so function can NULL-ify to express same fact of consumed mbuf. This matches classic OpenBSD/pf style. In one case you use FreeBSD style and in two cases OpenBSD.

IMHO, the new function should be used consistently using either return value or the pointer. Personally I prefer FreeBSD style over OpenBSD/pf.

[kp]

In D35158#797201, @glebius wrote:

The new function is bool, to tell if the packet was consumed. Let's call this modern FreeBSD style. You also pass a pointer to pointer, so function can NULL-ify to express same fact of consumed mbuf. This matches classic OpenBSD/pf style. In one case you use FreeBSD style and in two cases OpenBSD.

IMHO, the new function should be used consistently using either return value or the pointer. Personally I prefer FreeBSD style over OpenBSD/pf.

That's not quite right. The return value indicates an error. For example when we fail to allocate the tag, or if we're configured to shape the packet (i.e. dnpipe/dnrpipe != 0) but dummynet is not loaded.

We can return 'true' and yet not have eaten the mbuf. I'll change the return type to an int (and return ENOMEM on error) to make it a bit clearer.

[kp]

Change return type to int, to clarify that this is an error return.