Refactor Xss::attributes() to allow filtering of style attribute values

@very_random_man re #55: hook_editor_xss_filter_alter() and swapping the class used is only useful if the filtering is happening via a text editor. It's of no help if something else like Views is calling Xss::filter().

The patch from #60 has not applied for D9.5.9
Re-roll for 9.5.9

#60 missing "datetime", #62 was working fine for me in 9.5.9, so rerolled the same patch for 10.1.x

The proposed patch now only applies to attributes using single quotes. I'm updating the patch (for 9.5.x) to work for double quotes as well.

This should be moved over to D10 as D9 is approaching EOL and D10 is where such maintenance should reside.

I have come across this recently and I tried to organize the reasoning behind the whole issue and come to a conclusion.

Impact

First, I think I understand the reasoning of the current behavior, but here is the result - which I think is worse than the intentions.

Step 1: Security-aware developer puts a filter in the text format, such as HTMLPurifier or HtmLawed, in order to find a balance between allowing some inline styles capabilities but mitigating at least some risks.
Step 2: Drupal core says, sorry developer, you cannot have a partly secure setup. If you need inline styles, go ahead and remove your security filter so that you have a completely insecure setup.
Step 3: Client goes "I came to Drupal from X system for being a great CMS, but I cannot do such a basic thing like setting the size of some text and adding some custom padding, Drupal is so limiting me".
Step 4: Account manager sees the dollars going away, ok developer let's remove the security filter, content editors are trusted users.
Step 5: Attacker gains access to a content editor's account and engineers an XSS attack, or click-jacking, or whatever pleases, through script tags or style attributes.
Step 6: Administrator user views or edits that content item and is subjected to the attack.

Drupal core allows me as a developer/site builder to have a completely insecure text editing configuration, if that's what I deem appropriate for my use case. But it prevents me from having a reasonably secure setup.

Proposed solutions

First, the idea is that the content is stored "as is" in the database and the filtering happens during rendering. This is intentional because if something would be filtered before saving it into the database, that's gone forever leading to errors. This is exactly what happens though with this issue and it is inconsistent with this design.

What are the disadvantages of delegating the rendering to the text editor? CKEditor has its own system for this, being Advanced Content Filtering in v4 or General HTML Support in v5. Provide the default configuration for what is provided by Drupal core i.e. CKEditor + the default text formats, and let developer configure the text editor as needed if they customize their setup.

Alternatively, would it make sense to load the same security filters that are configured for the frontend rendering - which I believe are determined by the FilterInterface::TYPE_HTML_RESTRICTOR constant, load them in the text editing rendering i.e. in the Standard editor XSS filter?

This way I get the same result in both frontend and text editing rendering. It does violate though the design of not overriding the original data. Could be offered though as an option to the developer to decide.

Keeping the HTML code safe is a massive subject, and that's why there exist specialized libraries for it. Trying to reinvent this within Drupal core (referring to allowing simple properties only within inline styles), will only deliver a mediocre solution, locking developers into it - unless you get into complex efforts to override/extend/replace classes, increase code maintenance for core and contrib/custom modules. Better let developers use the tools that specialize in solving these issues.

I have just reviewed this this week and I am fairly unfamiliar with components involved, so if I'm misunderstanding this part of the stack please do correct me.

Documentation/help

Lastly, after a solution is decided, I think what is really missing is guidance for the developer/site builder. I think that the majority of developers/site builders would not be familiar with all these details, the security risks, what alternative solutions to provide to text editors. So let's create a documentation page with advice like the ones @Wim Leers suggested, plus an explanation of this issue i.e. the frontend/text editing rendering and how to properly configure both the text editor and the text filters, and link to that documentation in the text format create/edit pages.

Re #66: yes, but this issue does not just affect text formats/editors.

It also affects things like views rewrites, where you might want to rewrite and add a style attribute that is benign - passing a css property value through to a stylesheet for example. No text editor is involved there.

Update #43 for 10.1

I have update the #64 patch for the last core update 10.2.3

update patch with LF format

the final patch rename correctly.

This is a reroll of #64/#71 for 10.2.x.

Recommend using MRs

Feature will need test coverage

Issue summary should use standard template for reviews and committers

Re-rolling #43/68 for 10.2.3