vol: fix nextVnodeUnique roll over

Fixes for the per volume nextVnodeUnique counter roll over. Uniquifier number 1
is reserved for the root vnode, so reset the unique count to 2 when the
nextVnodeUnique counter rolls over.

Update the disk backed V_uniquifier count when the in-memory nextVnodeUnique
counter rolls over during the creation of a new vnode. If the nextVnodeUnique
rolls over when V_uniquifier is UINT32_MAX, then the V_uniquifier is not updated
and remains at UINT32_MAX until the next VUpdateVolume_r() call for the volume.

This bug is usually masked by the VBumpVolumeUsage(), which on every 128 volume
accesses, bumps the V_uniquifier to be 200 more than the current
nextVnodeUnique counter.  This causes the V_uniquifier to roll over before
reaching UINT32_MAX.  (The number of access before updating the headers is set
in the usage_threshold volume package option, which is currently set to 128 by
default.)

The following shows the unique counters for a series of vnode
creation/deletions before this commit.  The nextVnodeUnique rolls over to 1,
and the uniquifier is not reset.  The `usage_threshold' was set to a value
greater than 200 to avoid the VBumpVolumeUsage() calls during this test run.

fid = 536870918.4.4294967294, nextVnodeUnique = 4294967295, uniquifier = 4294967295
fid = 536870918.4.4294967295, nextVnodeUnique = 0, uniquifier = 4294967295
fid = 536870918.4.1, nextVnodeUnique = 2, uniquifier = 4294967295
fid = 536870918.4.2, nextVnodeUnique = 3, uniquifier = 4294967295

The following shows the unique counters after this commit:

fid = 536870918.4.4294967294, nextVnodeUnique = 4294967295, uniquifier = 4294967295
fid = 536870918.4.4294967295, nextVnodeUnique = 0, uniquifier = 4294967295
fid = 536870918.4.2, nextVnodeUnique = 3, uniquifier = 203
fid = 536870918.4.3, nextVnodeUnique = 4, uniquifier = 203

Change-Id: I438670200bf97baeac1486eda7df4cf243aabfc4
Reviewed-on: http://gerrit.openafs.org/10616
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
vol: reset nextVnodeUnique when uniquifier rolls over

The on disk uniquifier counter is set to 200 more than the current
nextVnodeUnique counter when the volume information is updated to disk. When
the nextVnodeUnique is near UINT32_MAX, then the uniquifier counter rolls
over.  This can happen during a volume header update due to
VBumpVolumeUsage_r().

With this change, the nextVnodeUnique customer is reset to 2 and the
uniquifier is reset to 202 when a roll over occurs. (uniquifier of 1 is
reserved for the root vnode.)

With this change, the number of possible uniquifier numbers is limited to
200 less than UINT32_MAX.

The following shows a series of vnode creation/deletions to illustrate
the uniquifier rollover before this commit:

fid = 536870918.4.4294967114, nextVnodeUnique = 4294967115, uniquifier = 4294967295
fid = 536870918.4.4294967115, nextVnodeUnique = 4294967116, uniquifier = 4294967295
fid = 536870918.4.4294967116, nextVnodeUnique = 4294967117, uniquifier = 21
fid = 536870918.4.4294967117, nextVnodeUnique = 4294967118, uniquifier = 22

and after this commit:

fid = 536870918.4.4294967115, nextVnodeUnique = 4294967116, uniquifier = 4294967295
fid = 536870918.4.4294967116, nextVnodeUnique = 2, uniquifier = 202
fid = 536870918.4.2, nextVnodeUnique = 3, uniquifier = 202
fid = 536870918.4.3, nextVnodeUnique = 4, uniquifier = 202

Change-Id: I93c8a7cf47e39b8701265d6507cfc4f8c1352ddc
Reviewed-on: http://gerrit.openafs.org/10617
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>