Wiki page HTML contains an unchanging bit that just sets JS variables
about what site this is, then calls an external <script> to fetch site
notice text.  It also includes a facility to fetch a geolocation data.

That second level is a stable URL which can be heavily cached within
squids *and* cleanly purged on sitewide updates. This script is currently
called Special:BannerController.

BannerController fetches list of notices available by calling out to
a third <script>, this time with the site info (project and language)
and geolocation info in the query string. The third script, called
Special:BannerListLoader provides list of currently available sitenotices
for that match the given site and geolocation profile. It is possible
that a number of notices will be available for the given site and user
parameters.

The fourth level is the bit that would provide the actual site notice
text, and could be cached arbitrarily long in both squids and final user
agents, since changed versions will get a new URL with a version number
one level up.

The theory here is that it should interact better with big-site caching.
A user agent's first hit to the wiki will look something like:

* Load wiki page HTML
* Load Special:BannerController JS
* Load Special:BannerListLoader JS
* Load Special:BannerLoader JS

A hit to another page on the same wiki can skip step two and three, but
may need to load notice in step four (if there is more than one available)

* Load new wiki page HTML
* skip cached Special:BannerController JS
* skip cached Special:BannerListLoader JS
* Load Special:BannerLoader JS

Then if the site notice changes, the system only has to purge that
constant Special:BannerListLoader URL from squids, and right away at
the next hit the user agent sees:

* Load new wiki page HTML
* skip cached Special:BannerController JS
* Load new Special:BannerListLoader JS
* Load new Special:BannerLoader JS

Caching Special:BannerListLoader for a while could delay visibility of
changed site notices until the allowed age runs out, but if we manage
*scheduled* site notices, we could send cache headers which will run
out at the expected changeover time.

It might be nice to allow for quick corrections though, so caching for
weeks at a time might not be wise. ;)