A new configuration variable $wgUseLegacyParserByDefault will allow opting out (until the next LTS release).

Major components of this work are subtasks:

1. T310512: Parsoid and the legacy parser should emit exactly the same ParserOutput metadata
   • The way we do this with confidence is via T310511: Metadata comparison testing between Parsoid and the legacy parser: building a testing infrastructure similar to the one we have with visualdiff and round-trip testing so that we can quantify metadata differences between legacy and parsoid.
2. T393716: [EPIC] RefreshLinksJob should use Parsoid-generated metadata
   • Probably this will use the parallel parsing done in T310511 for comparisons, and then just selectively start using the Parsoid parse instead of the legacy parse (unless $wgUseLegacyParserByDefault is set).
   • It is possible this will be a wiki-by-wiki deploy the same way we've done Parsoid Read Views roll out, depending on how the comparison looks.
3. T370926: [EPIC] Use Parsoid for UX (optional)
   • We can meet our goals for MW 1.47 if UX message parsing is the *only* thing using the legacy parser, but ideally we should at least provide an experimental option to enable use of Parsoid for UX. (Maybe separate config than $useLegacyParserByDefault.)
4. T420491: ParserOptions::newFromAnon() should return `useParsoid` set to `true` by default.
   • This is a small code change but fixing CI is probably a much larger task: any test which relies on particular parser output will need to be updated.
   • The ParserMigration extension should still work, but in an opposite sense (allowing individual users to opt out of Parsoid).
   • Our mediawiki-config will have to be flipped, with individual wikis setting $wgUseLegacyParserByDefault=true (or maybe still via the ParserMigration extension).