Draft: Use HTML5 parser for individual filter instantiations

What does this MR do and why?

Since Use HTML5 parser to close tags left open (!228223 - merged), we use an HTML5 parser when taking output from the Markdown-to-HTML filter and transforming it into a Nokogiri document. This is a good thing

However, when instantiating individual filters and feeding them HTML as input — which we do exclusively but extremely frequently in specs — we let HTML::Pipeline's default DocumentFragment choice choose the parser. That's Nokogiri::HTML::DocumentFragment, the old HTML4 one.

This means our individual filter specs test with input that's not parsed the same way as the actual pipelines used in production code do. This can have surprising or misleading results.

We fix the discrepancy by overriding the HTML::Pipeline::DocumentFragment alias, with a spec to make sure it stays that way.

How to set up and validate locally

You can try instantiating a filter manually (one that you don't expect to actually modify your input; just for forcing the HTML parse), run input through it, and test that the resulting document looks like it was parsed according to HTML5. See !228223 (merged) for an example of such input. You can compare with running it through a minimally parsing pipeline, which should do the right thing already.

On master

...

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.