Next step of netlock pressure decreasing in pppx(4).

Next step of netlock pressure decreasing in pppx(4).

The kernel lock is still taken when we access pppx(4) layer through
device node. Since pipex(4) layer doesn't rely on netlock anymore, and we
don't acquire it when we access pipex(4) from pppx(4) layer, kernel lock
is enough to protect pppx(4) data. Such data doesn't accessed from packet
processing path, so there is no reason to block it by netlock acquiring.

Assume kernel lock as protection for `pxd_pxis' lists and `pppx_ifs' tree.
The search in `pppx_ifs' tree has no context switch. There is no context
switch between the `pxi' free unit search and tree insertion.

Use reference counters to make `pxi' dereference safe, instead of holding
netlock. Now pppx_if_find() returns `pxi' with reference counter bumped,
and newly introduced pppx_if_rele() used for release this `pxi'.

Introduce pppx_if_find_locked() which returns `pxi' but doesn't bump
reference counter. pppx_if_find_locked() and pppx_if_find() both called
with kernel lock held, but keep existing notation where _locked()
function returned data with non bumped counter.

Mark dying `pxi' by setting `pxi_ready' to null, so concurrent thread
can't receive it by pppx_if_find().

The netlock is left around modification of associated ifnet's
`if_description'. This is unwanted because `if_description' never accessed
within packet processing path, but this require ifnet locking
modification, so keep this to the following diffs.

ok bluhm@