Work in progress on the bus retry backoff fixes + tests
Fixed ERRAI-687: gradual backoff during reconnect attempts

I've introduced a test for this in the 404 error case. Unfortunately, there is logic in the client bus that does different things depending on the specific status code in the response. Testing all HTTP status codes is unfortunately prohibitive: it takes about 20 seconds per test, so we'll have to settle for partial coverage.

The new test also uncovered a problem with HttpPollingTransportHandler: it wasn't actually cleaning up all its timers when the bus told it to stop. This is fixed now too.

The fixes I made to the code itself, then:

* ClientMessageBusImpl.init() will now delay for a growing amount of time when there hasn't been a successful connection attempt in a while
* Fixed leaking timers in HttpPollingTransportHandler that persist after the bus has stopped and apparently thrown the whole transport handler away

It would be nice to randomize the existing throttling mechanism in the transport handlers. It would be even nicer to wire the transport handlers into the bus's own backoff mechanism, since the various handlers seem to operate independently at the moment.