Embed: replace pyquery with selectolax

[stsewd]

Don't introduce a new dep.
MkDocs doesn't work since it doesn't have fjson files,
I'm deleting the test for mkdocs for now,
I'll add support for MkDocs once we have the parsing done in a more
general way (soon!).

Based on #7986

[humitos]

I don't want to block this work, but I want to say that I don't feel super comfortable with this change considering the low amount of tests that we have and the weak this code has been being all this time.

I'm afraid that we could break all/many/few/random popups on project's production documentation without noticing at all. Basically, I think the cost could be too high and there is almost no benefit on swapping pyquery by selectolax at this point.

[stsewd]

I don't want to block this work, but I want to say that I don't feel super comfortable with this change considering the low amount of tests that we have and the weak this code has been being all this time.

We already have a bunch of tests #7986

I'm afraid that we could break all/many/few/random popups on project's production documentation without noticing at all. Basically, I think the cost could be too high and there is almost no benefit on swapping pyquery by selectolax at this point.

We are going to be able to share more code from the search parsers, those supporting mkdocs

[ericholscher]

I agree that we should hold off on this for now. I think we want to think about a way to create a "v3" of the embed API that does a few things:

• Has a design doc
• Major changes to backend code
• Change API response
• Solid CDN support
• Has public docs

I think these major breaking changes should likely go into that. We want to keep the old v2 stable while we deprecate it, and move most of this new work into the new API since it will have more thought behind it.

[stsewd]

In my defense here, the output changing would be very weird as the css selectors are the same and this is changing the html parser used, the parsers don't change the html. We didn't have tests before, so we don't know if any change is going to "break" it (as users rely on html, I don't see that really breaking as opposed to change how we return those elements, which this isn't changing). I do agree on having breaking changes in the response and more docs on v3 since v2 is being already used in the wild.

[humitos]

I think we should close this PR and start the v3 endpoint using selectolax if that's better. I don't think there are good reasons to change the backend library we are using at this point.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[humitos]

Closing for now. We can come back if we feel it's required.

Related to #8222