fix(gateway): ensure directory listings have Content-Type text/html

[Lekensteyn]

Files already have an explicit Content-Type set. Be sure to do this for
directory listings as well to avoid a fallback to autodetection in
net/http. That fallback fails when a ResponseWriter is installed that
performs compression.

[welcome]

Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions
  and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the
  rest) and in its best form. Follow the code contribution
  guidelines
  if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

• A maintainer will triage and assign priority to this PR, commenting on
  any missing things and potentially assigning a reviewer for high
  priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

[Stebalien]

How exactly did you run into this problem?

[Lekensteyn]

One of the configured corehttp.ServeOptions in our gateway added gzip compression if the client supports it via Accept-Encoding. That resulted in empty Content-Type headers when compression is enabled, and for some reason it resulted in a reverse proxy displaying the HTML index as plain text.

[Stebalien]

Ah, I see.

[Stebalien]

(i.e., inside the branch and again before rendering the template)

[Lekensteyn]

There is only one error case now, namely when the directory contents cannot be read. In that special case, the content-type will be text/plain while the HEAD request will return text/html. I'd say that is acceptable.

Since the previous version, #4233 got merged which introduces a new edge case: if ipfs-404.html is present, the directory index is not shown. However even for that case, text/html is appropriate.

[Stebalien]

Thanks!