Review all usages of Xss::filter(), Xss::filterAdmin(), and Html::escape()

This is quite old!
I was digging into an issue with inline templating within Views and found this piece of code from \Drupal\views\Plugin\views\PluginBase::viewsTokenReplace():

      // Use the unfiltered text for the Twig template, then filter the output.
      // Otherwise, Xss::filterAdmin could remove valid Twig syntax before the
      // template is parsed.

      $build = [
        '#type' => 'inline_template',
        '#template' => $text,
        '#context' => $twig_tokens,
        '#post_render' => [
          function ($children, $elements) {
            return Xss::filterAdmin($children);
          },
        ],
      ];

      // Currently you cannot attach assets to tokens with
      // Renderer::renderInIsolation(). This may be unnecessarily limiting. Consider
      // using Renderer::executeInRenderContext() instead.
      // @todo https://www.drupal.org/node/2566621
      return (string) $this->getRenderer()->renderInIsolation($build);

Here, even if we are using Twig's render engine, filterAdmin is called on post_process without any way to bypass it. In my case, I have an inline template that includes an image field rendered with a responsive style. The <picture> and <srcset> tags are dropped by this post process so I must use an external template instead of the builtin feature of views.

I had a look and only found this call that could easily be removed. But I might have missed some others.

I think several calls have been removed over the years ( #2569381: Drupal\views\Plugin\views\area\Result does an unnecessary XSS::adminFilter() → for example).

@duaelfr I'm not sure this is related. I think there was some issue about being able to set the list of allowed tags in view templates but I can't find it.

Not sure I follow why https://www.drupal.org/project/drupal/issues/2036219 is no longer needed.

@smustgrave Re: #26, wrong issue?

Updated comment sorry!

Not sure I follow why Markup::create(Xss::filterAdmin($element['#value'])); is no longer needed.

#markup already calls Xss::filterAdmin() when it is rendered.

A call in the HtmlTag element itself; very nice!

FWIW regarding #22 which I did not read closely before, I think that is works as designed.

Is any of #9 forward-portable?

The patch from #9 blindly replaces Xss::filter() calls with a render array, even in places where the expected type is a string.
For example:

-    $safe_string->string = Html::normalize(Xss::filter($string, static::allowedTags()));
+    $safe_string->string = Html::normalize(['#markup' => $string, '#allowed_tags' => static::allowedTags()]);

This would definitely not work.

Which is why I did not use it as basis for the MR and started from scratch.

Ah good call; I did not actually review it. Thanks @prudloff.