Commit 9fd5160558 attempted to fix
races where the change cache watchers might still be running
after test shutdown. This was specific to some very short tests.
Unfortunately, one of those tests (test_concurrent_delete) exercises
a behavior where if no watch events ever reach the cache during
the test, then the cache key will still remain in the cache.
It is not clear whether this is a behavior that could occur
in reality, or if it is a side-effect of simulating two cache
actors with the same cache object. If it could happen in reality,
it may indicate a minor bug/leak in the change cache. The best
way to resolve this might be to switch the change cache to use
a persistent recursive watch (possibly via the ZuulTreeCache)
in a future change.
In the mean time, let's try a second approach to make these tests
robust: give the change cache a stop method that will abort any
calls to ZK after it is called. This should avoid the underlying
problem of delayed watch callbacks attempting to access zk after
shutdown.
Change-Id: I15133bd5b612e492ddb51e903e9ee7944279cfc3
62ac6d4309