Adjust Tx rate limiter for unused transactions

Adjust Tx rate limiter for unused transactions

I have a test that submits an arbitrary number of config transactions
and I noticed it can take an unusually long time depending on the
initial Tx rate limit setting. With the default setting of 100 it was
very slow even though I could see the adjusted limit increasing where
the elapsed time should've been much shorter.

It turns out the config datastore rate limit wasn't issue. When a
front-end Tx is created, a Tx instance is created in each data store.
The operation Tx's were unused but they artificially limited the config
rate since the operational rate wasn't getting updated, ie it stayed at
100.

I made changes to adjust the rate limit for unused Tx's if there have
been no prior "real" Tx's for that data store. In this case, the
percentile metrics will be 0 so I basically adjust to the current rate
from the other data store. I think this makes sense if we have no other
data to go by.

This required some infa changes so the ActorContext could get access to
the metrics timer for the other data store. Mainly, we need a global
MericsRegistry and JmxReporter across both data stores. I reused the
MetricsReporter class for this to get the static instance (with changes to
support multiple MetricsReporters per domain name). I also added
a static method to get all the data store names.

I found it useful to see the current rate limit via JMX so I added a new
DatastoreInfoMXBean to report it.

Change-Id: I09def94e40a1fe57779e76763e48696140f3a125
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>