altq: Implement two level "rough" priority queue for plain sub-queue

The "rough" part comes from two sources:
- Hardware queue could be deep, normally 512 or more even for GigE
- Round robin on the transmission queues is used by all of the multiple
  transmission queue capable hardwares supported by DragonFly as of this
  commit.
These two sources affect the packet priority set by DragonFly.

DragonFly's "rough" prority queue has only two level, i.e. high priority
and normal priority, which should be enough.  Each queue has its own
header.  The normal priority queue will be dequeue only when there is no
packets in the high priority queue.  During enqueue, if the sub-queue is
full and the high priority queue length is less than half of the sub-
queue length (both packet count and byte count), drop-head will be
applied on the normal priority queue.

M_PRIO mbuf flag is added to mark that the mbuf is destined for the high
priority queue.  Currently TCP uses it to prioritize SYN, SYN|ACK, and
pure ACK w/o FIN and RST.  This behaviour could be turn off by
net.inet.tcp.prio_synack, which is on by default.

The performance improvement!

The test environment:
All three boxes are using Intel i7-2600 w/ HT enabled

                          +-----+
                          |     |
                +->- emx1 |  B  | TCP_MAERTS
+-----+         |         |     |
|     |         |         +-----+
|  A  | bnx0 ---+
|     |         |         +-----+
+-----+         |         |     |
                +-<- emx1 |  C  | TCP_STREAM/TCP_RR
                          |     |
                          +-----+

A's kernel has this commit compiled.  bnx0 has all four transmission
queues enabled.  For bnx0, the hardware's transmission queue round-robin
is on TSO segment boundry.

Some base line measurement:
B<--A TCP_MAERTS (raw stats) (128 client): 984 Mbps
    (tcp_stream -H A -l 15 -i 128 -r)
C-->A TCP_STREAM (128 client): 942 Mbps (tcp_stream -H A -l 15 -i 128)
C-->A TCP_CC (768 client): 221199 conns/s (tcp_cc -H A -l 15 -i 768)

To effectively measure the TCP_CC, the prefix route's MSL is changed to
10ms: route change 10.1.0.0/24 -msl 10

All stats gather in the following measurement are below the base line
measurement (well, they should be).

C-->A TCP_CC improvement, during test B<--A TCP_MAERTS is running:
                        TCP_MAERTS(raw)  TCP_CC
TSO prio_synack=1       948 Mbps         15988 conns/s
TSO prio_synack=0       965 Mbps          8867 conns/s
non-TSO prio_synack=1   943 Mbps         18128 conns/s
non-TSO prio_synack=0   959 Mbps         11371 conns/s

* 80% TCP_CC performance improvement w/ TSO and 60% w/o TSO!

C-->A TCP_STREAM improvement, during test B<--A TCP_MAERTS is running:
                        TCP_MAERTS(raw)  TCP_STREAM
TSO prio_synack=1       969 Mbps         920 Mbps
TSO prio_synack=0       969 Mbps         865 Mbps
non-TSO prio_synack=1   969 Mbps         920 Mbps
non-TSO prio_synack=0   969 Mbps         879 Mbps

* 6% TCP_STREAM performance improvement w/ TSO and 4% w/o TSO.
libz: Add symbol versions (not active)

Every time symbol versioning is added to a system library, it will
require a full buildworld for the next build.  In addition, if the major
version isn't bumped, it will break the binary packages that link to it.

The working plan is to add versioning to libaries, but not hook it into
the build unless "RELEASE36" is defined.  When all the libraries have
been versioned, then these conditions will be removed so only one full
buildworld will be required to minimize inconvenience to users.

All versioned libraries will be bumped with the exception of libc as it
has already been bumped for branch 3.5, thus libc.so.7 is already
available.  In other words, we bump to avoid package breakage and that's
no longer an issue for libc.

After this commit, libz will build as before unless RELEASE36=yes is
defined in make.conf or passed to make during buildworld.
Merge branch 'master' into gsocdrm_github
hammer2 - pfsmount -> clustermount separation part 1

* Start working on turning the hammer2_pfsmount structure into an
  abstracted PFS 'cluster' structure.

* Move hammer2_inode's allocation infrastructure to the pmp (except
  for the super-root inode which has no pmp).  It was previously
  hmp-centric.
kernel - Increase KVM default for 32-bit systems from 1GB to 1.5GB

* Increases KVA_PAGES default from 256 to 384, giving the kernel 1.5GB
  of KVM and userland 2.5GB (instead of 1/3).

Numerous people running 32-bit systems are hitting resource limits and
actually running out of KVM.  There are many reasons for why this is
happening.  It isn't simply a resource-tuning issue because most of the
resource limits we have today are already quite reasonable.  It's when
the system combines to fully utilize multiple resources where the problems
begin.  Tuning-down the resources impacts performance too much and makes
the systems less usable.  PCI resources tend to reserve larger areas,
system structures are fatter, and many other issues crop up.

In addition, 32-bit systems today can be greatly extended by adding swapcache
and swapcache requires significantly KVM resources.  For example, adding
64GB of swapcache eats ~64MB of ram and heavy tmpfs use often requires an
even higher ratio (64GB swap w/ kern.maxswzone=128m in /boot/loader.conf).
With the price point for SSDs coming down, 256GB and larger SSDs are far
more common these days and we want even 32-bit systems to be able to make
use of them.

On a fresh system boot well over 512MB of KVM out of the (previous) 1GB
space is already accounted for.  This leaves precious little for dynamic
expansion of system structures.

This leaves us with one real option... increase KVM and decrease UVM.
By increasing KVM from 1GB to 1.5GB we nearly double the KVM available to
the kernel for dynamic expansion of system structures.  User virtual memory
is reduced from 3GB down to 2.5GB.  While this may impact some applications
such as Perl, those applications are already tending to run on the edge
anyway and, in fact, modern application development is starting to assume
64-bit address spaces for optimal operation anyway.

I've come to the conclusion that it is better to move the line on UVM down
in order to completely solve the KVM issue for system resources on 32-bit
systems.
libarchive: Add symbol versions (not active)
systat/ip: Unbreak UDP stats
kernel - Document bugs in sendfile that we currently punt on

* sendfile tries to soft-busy the VM pages it backs the mbuf with.  This
  is meant to prevent the VM page's data from being modified while TCP
  is playing with it.  However, it doesn't work.  There are two issues.

* (1) The page still may be mmap()'d writable.  A simple vm_page_protect()
      would fix this.

* (2) The page may be associated with a buffer cache buffer and can be
      modified via a VOP_WRITE through that buffer regardless of whether
      soft-busy or busy is set.  This is a real problem.

      Even if we find and discard the buffer it can just be reinstantiated
      and wind up with the same problem.

From-discussion-with: jeffr, rookie on IRC
Merge branch 'master' into gsocdrm_alter