Only set content-length header in specific situations

This changes the method to look like this:

  public function setContentLengthHeader(ResponseEvent $event): void {
    $response = $event->getResponse();
    if ($response instanceof StreamedResponse) {
      return;
    }

    // Do not add header for 100s and 500s, see
    // https://www.rfc-editor.org/rfc/rfc9110.html#name-content-length.
    if ($response->isInformational() || $response->isServerError() || $response->isEmpty()) {
      return;
    }

    if ($response->headers->has('Transfer-Encoding')) {
      return;
    }

    $content = $response->getContent();
    if ($content === FALSE) {
      return;
    }

    $response->headers->set('Content-Length', strlen($content), TRUE);
  }

Some of this is inspired by what's in \Symfony\Component\HttpFoundation\Response::prepare() which is the last thing called by \Drupal\Core\DrupalKernel::handle() before we send the request.

So as it turns out Symfony is already fixing quite a bit of this for us, but I still think we shouldn't be adding this header in when we know we're just going to remove it later.

One thing I wonder is just we remove

    if ($response instanceof StreamedResponse) {
      return;
    }

as this is covered by

    $content = $response->getContent();
    if ($content === FALSE) {
      return;
    }

@andypost how is that relevant to this issue? Do they require the content-length header? FWIW server side gzip/brotli must adjust the content-length header - as suggested here https://serverfault.com/questions/783029/apache-returns-invalid-content-...

I'm thinking that we should separate out the isServerError() check as that's the one thing that's not per RFC but down to some oddness in Drupal's error handling. Then if we fix that we could remove it. Pushed that change to the MR.