CFR: routing table locking

[Sam Leffler]

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

This is an extensive set of changes to lock routing table entries.  There 
are some issues with these changes that will need to be resolved before 
committing the work.  In particular the per-entry mutex is stored in the 
rtentry structure and this struct is visible to user applications like 
route(8).  This must be fixed.  For now I've #ifdef'd the mutex to be 
included only in the kernel.  We'll either need to use an indirect 
reference to a mutex or, more likely, introduce an externalized version of 
struct rtentry to decouple kernel operation from user applications.  It may 
be possible to jigger the code to make the lock in the entry be a leaf lock 
in which case we could use a mutex pool and a pointer to a mutex but I'm 
leaning more to decoupling the kernel from user apps as this has general 
benefits.

These changes have been in use on 4 of my machines for several weeks.  IPv6 
has only been lightly tested.  In general I consider the code very lightly 
tested so don't be surprised if you encounter issues.  Also, because of the 
wide visibility of the routing table in the system I may have missed some 
uses that need locking.  There are a couple of LOR issues to be resolved. 
In particular I recall there is one with the ARP cache.

Another issue is that these changes do not include multicast routing.  That 
code has been changing recently so I left it alone.  I'm not well setup to 
test multicast routing so if someone with an existing setup is interested 
in tacking this please let me know.

Note there is one API change buried in these diffs.  I dropped the last 
parameter to rtredirect that allowed callers to receive a reference to the 
associated entry.  This was not used in the system and introduced issues 
for locking.

	Sam