CM Fix Bug 6948912: DB connector sends many small feeds which slow down the GSA.

When sending many feeds with only a few records in each feed to the GSA,
the GSA will become backlogged in its feed processing.  

Diffing connectors tended to exacerbate this issue with two behaviours
that could trigger sending small feeds:

1) The RepositoryMonitor threads feeding the ChangeQueue and the 
   QueryTraverser threads draining the ChangeQueue operated at nearly
   the same rate. As a result, when a traversal batch was requested,
   the ChangeQueue would get drained into the CheckpointAndChangeQueue,
   and subsequently added to the DocumentList.
   However, there were usually only a few documents ChangeQueue, 
   resulting in returned batches of 40-50 documents.

   This was easy to fix. When polling the ChangeQueue for changes,
   allow a small timeout of 1/4 second, waiting for a change to be
   added to the queue should it be empty.  As long as the queue is
   being fed by the producer (Monitor) at a reasonable rate, the 
   consumer will not give up so quickly when the queue runs dry.

2) The adaptive HostLoadManager algorithm is designed to maintain
   the target load by dropping the requested batch size if the
   connector is returning batches too quickly.  However,
   DiffingConnectors separate the actual repository traversal
   from the return of batches of documents - with the ChangeQueue
   in the middle. With a sufficiently large ChangeQueue, returning
   subsequent batches of documents would appear to be nearly
   instantaneous.  The HostLoadManager would notice that the
   connector could return full batches of documents in 1/10
   of a second, then attempt to regulate the throughput by
   turning down the traversal rate.

   In this case, the HostLoadManager and DiffingConnector
   algorithms are at odds.  The DiffingConnector behaviour
   would look like:
     - long delay
     - several full batches, returned very quickly
     - repeat
   The adaptive load management would start out with full
   batches, then scale back the requested batch size for
   subsequent batches as they are returned too quickly.
   Then reseting to the full batch size after the long delay.

   Here the adaptive load manager set a floor for the minimum
   batch size that was too low - 20 documents.  These tiny
   feeds are much more problematic for the GSA than previously
   believed.  This change sets the minimum allowed batch size
   to be the lesser of the configured load and target batch
   size.  In general, this will be hundreds of documents,
   rather than tens.  This will result in the traversal
   batches being more "bursty", for low configured loads -
   with many documents fed, followed by delays of a few
   minutes to maintain an average throughput.


Both of these changes should reduce the likelihood of 
sending many small feeds to the GSA.

Code Review:
http://codereview.appspot.com/6453111
Added tests for principals with different attributes in the feeds,
unqualified by domain name, and with a namespace, along with the
existing test for case-insensitive principals. See also bug 6863543.

Also made the System.out.printlns of the test name more consistent by
moving it to setUp.

Code review: http://codereview.appspot.com/6459082/