Parsoid/Minimal performance strategy for July release

Peak edit rates are around 50reqs/second across all Wikipedias. In July, we need to sustain rates close to that as the Visual Editor is scheduled to become the default editor on all Wikipedias. Parsoid itself can be scaled up with more machines. We do however use the MediaWiki API to expand templates and extensions and to retrieve information about images. This can mean hundreds of API requests on large pages, which would overload the API cluster.

We have a long-term performance strategy as outlined in our roadmap that will address the API overload problem. We might however not be able to implement enough of this before July. A minimal backup strategy to avoid overloading the API cluster is needed.

Leverage cached parse results to avoid API overload
We have a Varnish cache in front of the Parsoid cluster, which caches the parse result for a given revision. We can use this cached parse result to speed up subsequent parses. The main things we are interested in (template / extension expansions and image dimensions / paths) are available in the previous version and are marked up in a way that makes it relatively easy to extract and reuse.

Outline:
 * Retrieve previous version's HTML DOM from cache
 * Extract template, extension and image data from it and pre-populate internal caches with it
 * Parse new page, which will trigger API requests only on changed template transclusions / extensions / images.

Templates and images in particular can be modified, so we'll have to make sure our cached expansions are not getting too stale. Initially we could attach a timestamp to expansions and limit the reuse with a fixed TTL. Alternatively, we can re-render templates if the page was re-rendered by the PHP parser in the meantime in a LinksUpdate job (its cache timestamp has changed).