Calendar block incompatible with block caching

Issue Summary

On my site, I observed the calendar block being occassionally a few months off, i.e. instead of (now) November it showed other months. It mostly affected just anonymous users, across the whole site, and it was "locked" to the same month for long periods of time (until a new post was submitted, or cron run).

I tracked it down to an incompatibility of the calendar block against core block caching in D6, namely the "follow event calendar" feature, where the block is supposed to mirror how the full-page calendar is browsed. This may not work with block caching, as the cache always store just one version of the block. When the first page being viewed after a cache flush hits a calendar for other-than-current month, the block mirrors that, the resulting output getting cached, and then served to all other users with the same role (regardless their browsing, so hiding the default current month from them, serving a seemingly random other month instead).

--------------------------

How to reproduce:

- Have a Drupal 6 install with Event module, calendar (table) block enabled in a sidebar.
- Enable Block caching
- Optionally flush caches (shouldn't be necessary, but who knows...)
- Log out and browse as anonymous:

- On frontpage (or similar) observe the current month (for example November now) being correctly shown in the block.
- Click on the month name in table heading, to see the month as full page (or navigate otherwise to month view).
- Click on the little arrows around the month name in the page view (not in the block) to navigate a few months off (i.e. if now it's November 2009, the page now shows for example January 2010, path being like 'event/2010/01/11/month')
- Observe that the table in block doesn't follow the main view, and still shows the current month (i.e. November). This is the first part of the bug: With Block cache disabled, it'll show the month from main view (i.e. January), but with caching it can't follow.

- Now flush the block cache. Use an other browser (already logged in as administrator) to hit the button on Performance page, or else truncate the cache_block table directly, to avoid the cache rebuild being affected by intermediate browsing. (We're testing the case, where an anonymous visitor is browsing the site concurrently to the flush.)

- Back at the anonymous browser [showing the January page], refresh the page. Observe how the block now followed the main view (so it shows January too).
- Browse to the frontpage, or anywhere else, and observe how the block is frozen on that month (i.e. January). No matter where you go, you never see the current month (with today highlighted), it shows the cached January everywhere. This is the worst part of the bug.

Currently, the only workarounds known to me are to disable block caching (not desirable on busy sites), or disable the block in question (not really a solution).

---------------------------------

Proposed fix:

The attached patch simply just avoids the "follow event calendar" stuff, if block cache is enabled, so the mirroring of month-browsing is not attempted in that case. As for functionality, this is not really a change, as the feature didn't work with caching already: The block doesn't follow the page, because it's cached [i.e. fixed]. But however, now we don't even attempt to render the block with other-than-default month, avoiding both the inconsistency of display [depending on cache un/populated state] and danger of wrong data being cached.

So, in fact we keep the current functionality, only just fixing a bug. It's IMO acceptable to have current month in the block rather than a mirror of main page view (and I might argue that it's even better that way, just like, for example, the "Recent comments" block doesn't change as I browse forums), and with block cache disabled, all works just like before (no change in that case).