Deprecate FilterInterface::getHTMLRestrictions()' forbidden_tags functionality

Reroll patch with reroll diff.

Updated FilterAPITest.php as per FilterFormat.php changes.

9.4.x patch:

+++ b/core/modules/filter/src/Entity/FilterFormat.php
@@ -307,6 +307,7 @@ public function getHtmlRestrictions() {
           // Track the union of forbidden tags.
           if (isset($new_restrictions['forbidden_tags'])) {
+            @trigger_error('forbidden_tags for FilterInterface::getHTMLRestrictions() is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0', E_USER_DEPRECATED);
             if (!isset($restrictions['forbidden_tags'])) {
               $restrictions['forbidden_tags'] = $new_restrictions['forbidden_tags'];

Are there any docs we need to update too or is this an undocumented feature? Also could use a @grou

+++ b/core/modules/filter/tests/filter_test/src/Plugin/Filter/FilterTestRestrictTagsAndAttributes.php
@@ -54,11 +54,6 @@ public function getHTMLRestrictions() {
       }
     }
-    if (isset($restrictions['forbidden_tags'])) {
-      foreach ($restrictions['forbidden_tags'] as $tag => $bool) {
-        $restrictions['forbidden_tags'][$tag] = (bool) $bool;
-      }
-    }
 

Is this completely untested then apart from this test code that doesn't look excercised? Was going to say we should add @group legacy coverage, but that might be optional if it's completely untested and undocumented.

1. +++ b/core/modules/filter/src/Plugin/FilterInterface.php
   @@ -198,7 +198,6 @@ public function process($text, $langcode);
       *             the possible values are TRUE or FALSE: to mark the attribute
       *             value as allowed or forbidden, respectively
   -   *     -  'forbidden_tags': (optional) the forbidden tags
       *
   

   Needs a (deprecated) note in the 9.4.x patch.

Feedback on the D10 patch 1 of 2. My next step will be applying the patch to core locally and seeing if there's anything additional to remove or rephrase.

1. +++ b/core/modules/ckeditor5/src/HTMLRestrictions.php
   @@ -38,7 +38,6 @@
     * NOTE: Currently only supports the 'allowed' portion.
   

   This "only supports" clarification is misleading now that 'allowed' is the only supported key.

2. +++ b/core/modules/filter/src/Entity/FilterFormat.php
   @@ -376,28 +366,6 @@ public function getHtmlRestrictions() {
   -      if (isset($restrictions['allowed'])) {
   -        if (count($restrictions['allowed']) === 1 && array_key_exists('*', $restrictions['allowed']) && !isset($restrictions['forbidden_tags'])) {
   -          $restrictions['allowed'] = [];
   -        }
   -      }
   

   I noticed FilterAPITest was updated to reflect this removal, but should this actually be removed? It's a condition that is true when $restrictions['forbidden_tags'] is not present, so wouldn't we just remove the <code>isset($restrictions['forbidden_tags']) in the condition chain, but otherwise keep this the same

3. +++ b/core/modules/filter/src/Plugin/FilterInterface.php
   @@ -184,7 +184,7 @@ public function process($text, $langcode);
       *     - 'allowed': (optional) the allowed tags as keys, and for each of those
   

   It could be argued 'allowed' is still *optional*, because there won't be an error if it isn't present. That's not particularly helpful, though. It should communicate that 'allowed' needs to be present for the filter to be of any use.

D10 patch review 2 of 2, while installed on local core:

1. \Drupal\ckeditor\Plugin\CKEditorPlugin\Internal has forbidden tags logic
   

      if (isset($html_restrictions['forbidden_tags'])) {
           foreach ($html_restrictions['forbidden_tags'] as $tag) {
             $disallowed[$tag] = TRUE;
           }
         }
   

   It looks like this might suggest an even larger LOC-removal opportunity in this class? generateACFSettings might have it's return structure changed?

2. \Drupal\editor\EditorXssFilter\Standard::filterXss references 'forbidden' in a manner that is no longer accurate since a text format does not forbid tags anymore:
   

    // Therefore, we want to be smarter still. We want to take into account
       // which HTML tags are allowed and forbidden by the text format we're
       // filtering for, and if we're switching from another text format, we want
       // to take that format's allowed and forbidden tags into account as well.
       // In other words: we only expect markup allowed in both the original and
       // the new format to continue to exist.
   

3. I notice \Drupal\filter_test\Plugin\Filter\FilterTestRestrictTagsAndAttributes is still there. It seems like it (and its corresponding schema) is quite removable since it is not actually used by tests in 9.x either.

Setting to "Needs work" for visibility #21 fixes a test failure, but the feedback in #19-#20 needs to be addressed. (at least according to the interdiff)

#19 and #20 are either addressed or theres a good explanation as to why not. Lets move this to the next stage.

Committed/pushed the respective patches to to 10.x and 9.4.x, thanks!

Think this can also be commit in 9.5.x :)

@Wim Leers: yes it has! But I forgot - first commit since it opened and the muscle memory for 10.0.x -> 9.4.x is still there. Cherry-picked there too.