Race condition in GCUpdater shutdown

The test_filter test fails occasionally with a hang. The hang appears to be caused by the thread doing the updates not being in sync with the thread that starts it. Inspecting the hanging test with a debugger shows that the m_running variable was the probable culprit: if the thread that does the updates hasn't had the chance to start before a call to GCUpdater::stop() is made, the value of m_running would remain true even after the stop() call.

In theory this can happen with smartrouter in 2.5 if a service is created and then destroyed immediately. Given the unlikely nature of it, fixing the hang in 2.5 is not required.