CFR: bridge locking

[Sam Leffler]

http://www.freebsd.org/~sam/bridge.patch

This patch adds locking and also overhauls the bridge code some to do 
things like replace explicit numbers with #defines and cleanup the 
debugging code.  I also restructured the forwarding code to avoid grabbing 
the ifnet lock if possible and optimized the common case of bridging two 
interfaces.  There are a couple of LOR issues to be resolved before it can 
be committed.  In particular the output path has a LOR that can deadlock. 
I'm making it available for review now in case folks have other comments.

Beware that buried in these changes are a renaming of the bridge MIB 
variables to be under a net.link.ether.bridge. node.  Those changes will 
not be carried over into the committed code unless folks are interested 
(since it'll break lots of rc scripts).

Note that drivers that operate Giant-free with bridging need to release 
their "driver lock" before passing packets up.  Otherwise the up call can 
result in an immediate return through the start method and deadlock (unless 
the lock is marked to allow recursion, which should be eliminated if at all 
possible).  I've made these modifications for the em, wi, and sis drivers 
but have not committed them.  The fxp driver already does this and the ath 
driver has a totally different locking strategy where this doesn't occur. 
Short term dropping the lock around the up call will work but is 
suboptimal.  Long term we may want to revise the locking strategy for 
drivers to eliminate this issue.  This will likely be revisited when I get 
to more performance tuning (unless someone else does it--hint hint).

One other minor change: I moved the printf "BRIDGE 020214 loaded" under 
bootverbose.  Can anyone tell me what 020214 means?

This code has been in "production use" on my interior firewall (a soekris 
box) for a week.  This box runs with the sis driver Giant-free.

	Sam