LU-3527 nodemap: add nodemap kernel module

The nodemap kernel module manages groups of mounted clients
and allows policies to be applied to them. A nodemap will be
defined as a nodemap name, and id, a tree of NID ranges that
represents the clients that are included in the nodemap, and
values that represent a policy for the behavior of the
filesystem with respect to those clients.

Initially, the policies implemented for nodemap will be static
UID/GID mapping from client IDs to a canonical filesystem IDs.
Additional flags are provided to allow the filesystem to trust
the IDs from the client (apply no mapping) and allow UID 0
(rootsquash applied to an entire nodemap).

A default nodemap is automatically provided which implicitly
contains all the clients not otherwise specified by an NID
range.

Nodemap will allow the unmapped UID/GIDs to be specified on a
case by case basis.

Nodemaps will be managed on the MGS, and configurations pushed
out the the other servers in the filesystem.

This patch adds nodemap to the build system, and defines the
basic operation for managing the addition and deletion of
the nodemap definitions.

The ioctl for management of the nodemaps from userspace was
added. The commands for adding and removing nodemaps were
added to lctl, and the handlers in the mgs.

The data structures for the module were added in
lustre/include/lustre_nodemap.

Additions were made to the make system and the m4 macros
to build nodemap with the rest of lustre.

Unit tests for adding and removing nodemaps were added
to sanity-sec.sh.

Range and idmap management functions will be added in the
two subsquent patches.

Signed-off-by: Joshua Walgenbach <jjw@iu.edu>
Change-Id: I2d34fde7aae3c2b4af512ff2c1ace5115ed40a6a
Reviewed-on: http://review.whamcloud.com/8034
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Andrew Perepechko <andrew_perepechko@xyratex.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
LU-3558 ptlrpc: Add the NRS TBF policy

The TBF (Token Bucket Filter) policy schedules and throttles all
types of RPCs for traffic control purposes. It divides RPCs into
different types according to their NIDs or job IDs, and enforces
a RPC rate limit on every type. The handling of a RPC will be delayed
until there are enough tokens for the type. Different types are
scheduled according to their deadlines, so that none of them will be
starving even though the service does not have the ability to satisfy
all the RPC rate requirments of types. The RPCs with the the same
types are queued in a FIFO manner.

Signed-off-by: Li Xi <lixi@ddn.com>
Change-Id: I3f73dfbfb451cc44dfe5e0a575ec7ab5b90ac47e
Reviewed-on: http://review.whamcloud.com/6901
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Tested-by: Oleg Drokin <oleg.drokin@intel.com>