(bug 46797) There's an inconsistency in the feedback page view and the permalink view; it looks like the feedback page view is not up-to-date

After changing data (e.g. moderating feedback to "resolved"), some caches (e.g. cache for entries in the "unreviewed" and "resolved" filters) are purged.
After being purged, the following hit would perform a new query, fetch the updated data, and cache them again.

At times, the follow-up requests seems to happen before the DB slaves catch up; in which case incorrect, outdated, data is cached for an hour.

It looks like LoadBalancer already attempts to let slaves catch up to the master (for a short timeout, that is) and if that timeout is surpassed (= slave is lagging) a flag is set: mLaggedSlaveMode.
Given that it is possible to check if we're reading from a lagging slave, I can now also tell exactly when it's allowed to cache data (= not when it's lagged)

Oh; also, in theory (it's not the case in the current code), I can pass a certaim $wiki as parameter to getLB. This then got saved in a property, but if I were to call getLB() with another $wiki argument, it would re-use that existing connection (which was for another $wiki). I also fixed this.

Bug: 46797
Change-Id: I5653fa1bbdbec474ae91e281fdf4381f00db3975
Merge "(bug 46797) There's an inconsistency in the feedback page view and the permalink view; it looks like the feedback page view is not up-to-date"