Clean up handling of 'infinity'

Clean up handling of 'infinity'

There's a bunch of stuff that probably only works because the database
representation of infinity is actually 'infinity' on all databases
besides Oracle, and Oracle in general isn't maintained.

Generally, we should probably use 'infinity' everywhere except where
directly dealing with the database.

* Many extension callers of Language::formatExpiry() with $format !==
  true are assuming it'll return 'infinity', none are checking for
  $db->getInfinity().
* And Language::formatExpiry() would choke if passed 'infinity', despite
  callers doing this.
* And Language::formatExpiry() could be more useful for the API if we
  can override the string returned for infinity.
* As for core, Title is using Language::formatExpiry() with TS_MW which
  is going to be changing anyway. Extension callers mostly don't exist.
* Block already normalizes its mExpiry field (and ->getExpiry()),
  but some stuff is comparing it with $db->getInfinity() anyway. A few
  external users set mExpiry to $db->getInfinity(), but this is mostly
  because SpecialBlock::parseExpiryInput() returns $db->getInfinity()
  while most callers (including all extensions) are assuming 'infinity'.
* And for that matter, Block should use $db->decodeExpiry() instead of
  manually doing it, once we make that safe to call with 'infinity' for
  all the extensions passing $db->getInfinity() to Block's contructor.
* WikiPage::doUpdateRestrictions() and some of its callers are using
  $db->getInfinity(), when all the inserts using that value are using
  $db->encodeExpiry() which will convert 'infinity'.

This also cleans up a slave-lag issue I noticed in ApiBlock while
testing.

Bug: T92550
Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef