We were reloading siteconfigs on every single request, which was

unnecessary. It was only necessary to reload if the siteconfig had

changed since it was last used. This wasn't particularly time-consuming,

but it was extra work that shouldn't be needed, and it made it hard to

handle reloads of logging.
To track whether a siteconfig should be reloaded, we now check a private

flag on the SiteConfiguration. If it's not set, we perform a full reload

(which now restarts logging as well, something that was missing and hard

to do correctly before). If it is set, we do nothing.

Browsed around the site a bit and checked things affected by settings.
Reloaded settings and saw it go through the reload path.
Tested a multi-process setup:


Set up two devservers on two different ports, each connected to a single memcached.


Loaded a page on both. Saw the initial log messages about writing to /tmp/reviewboard.log.


Changed log settings on server1 to point to ~/reviewboard.log. Saw it reload the siteconfig

   and output the new log destination as part of that request.


Loaded a page on server2, and saw it reload logging, pointing to the new location.


Changed the logging destination back to /tmp/reviewboard.log on server2. Saw it reload and

   output the /tmp location.


Loaded a page on server1, and saw it reload logging, pointing to the new location.