tweak tun/tap kn_data to be more consistent with everything else.
for EVFILT_READ, kn_data is now like FIONREAD and reports how many
bytes there are to read. previously it would report how many packets
were available to read, which is not something i've seen anywhere
for EVFILT_WRITE, report the max number of bytes a write can do.
previously it was if_mtu bytes, now it is if_hdrlen + if_hardmtu
bytes, which is the same as what the write path uses as it's maximum
discussed with and ok visa@
avoid the use of a custom bpf copy function.
currently pflog prepares a pfloghdr and then passes that, the
original mbuf, and a pflog copy function to bpf. bpf matches on the
original packet, and then if bpf decides it wants the packet it
uses the custom function to copy the packet for userland to read.
the custom function patches the packet so you see the packet after
nat and rdr and af-to and so on. however, this means bpf is matching
on the original packet and reporting a patched packet.
this is also the only use of a custom copy function in the tree,
and it relies on some behaviours that should be internal to bpf to
get away with it.
this pulls the patching up so it's done before the packet is given
to bpf. this simplifies the code a bit, and means bpf is now matching
on and reporting the same packet. removing this custom copy code
also means that we can get rid of that functionality from the
ok sashan@ visa@