Hopefully fix the stale site configuration issue.

Review Request #1449 — Created March 4, 2010 and submitted

Hopefully fix the stale site configuration issue.

This change attempts to fix the stale site configuration issue. There were
a couple things that could potentially go wrong.

One is that the cache key used to synchronize the site configurations could
potentially go stale, preventing the expiration checks on other
SiteConfigurations from returning the correct value. To fix this, we now
populate the cache (onlyif it's not already set in the constructor), and check
whether the result is None when checking whether it has expired. If it is
None, then the key fell out of the cache since the particular thread with
that cached SiteConfiguration was last used.

Another is that something may be funky with saving timestamps, or with two
SiteConfigurations having identical timestamps (due to heavy traffic or
something racy). We now increment the value in the cache and compare that.
Integers are safer and this shouldn't be racy when using memcached, as
incrementing is atomic. However, if people use some other backend mechanism
(such as the file backend), this could still be racy if multiple processes are
trying to save simultaneously.

Unit tests have been added for this. The first synchronization unit test
worked before these modifications, but the latter (with the cache key expiring)
did not.
Ran the unit tests. They seemed to be fine. Couldn't reproduce this otherwise.
  1. I hope we finally have this issue licked.