BUG 3125 : Set Rate Limit just before acquiring a permit to avoid contention

BUG 3125 : Set Rate Limit just before acquiring a permit to avoid contention

During perfomance test performance is hampered by the rate limiting code. To
avoid the penalty of possible contention when setting the rate limit in a
separate thread from the one acquiring a rate permit this patch calculates the
new rate limit and sets it on the rate limiter on the same thread which
acquires the rate limit.

Moving the setting of the rate limit into the same thread which does the
acquiring of the permit did not have any discernable effect on performance so
I continued playing around and found that simply calculating the rate limit
can cause issues with performance. This happens because the Coda Hale metrics
Timer that we use to help calculate the rate limit is also synchronized
internally with a read write lock and that causes contention.

To fix the situation with the rate limit calculation I do not calculate the rate
limit everytime someone tries to acquire a permit but only after acquiring about 1/2 of
the last calculated rate limit.

To make it easier to understand/test the rate limiting code I have slightly refactored
the code. All the transaction rate limiting code is now in TransactionRateLimiter.

After making these changes I was able to get the same performance in the dsBenchmark
test as you would get from not using a rate limiter at all.

Change-Id: Ia7639ac3acdc08140fbf5eef03120f857dc44994
Signed-off-by: Moiz Raja <moraja@cisco.com>
(cherry picked from commit 89e2dda49ea99a79d510a9cc72ebcb09a9d879de)