gateway: return user-friendly HTML with HTTP errors

[lidel]

Currently, we return text/plain with context of err.Error() of some sort. This if fine for curl, but very user hostile in web browser context.

Proposed improvement

basic human needs (#298)

• add HTML template for errors to /gateway/assets
• detect when request had User-Agent header starting with Mozilla and return text/html responses for errors instead (same message, but presented nicely)
• short sentence: inform user what IPFS is, what gateway is, what content routing is and what failed based on the error code
• include links to project, docs, and discussion forums (explicitly link to help forum category, so people can find common answer/problem threads)
• Include basic pointers on how to diagnose 4XX 5XX errors
  • suggest testing with https://docs.ipfs.tech/reference/diagnostic-tools/
  • suggest self-hosting, and running client that verifies data (https://docs.ipfs.io/install/command-line/, https://github.com/ipfs/ipfs-desktop, https://brave.com/ipfs-support/)
  • if 400 or 404, suggest inspecting CID (https://cid.ipfs.tech/) or DAG (http://explore.ipld.io) (or installing IPFS Desktop)

nice to have

below could be a follow-up PR. may not be a good idea to hardcode another HTTP endpoint and use of https://pl-diagnose.onrender.com for every gateway deployment, perhaps better to wait for ipfs/in-web-browsers#207 and webtransport transport rollout. or we could use https://pl-diagnose.onrender.com and https://cid.contact/ as default, with config options to change/disable them.

• built-in self-service when content routing failed
  • present a button that runs DHT/IPNI checks against failed CID (https://pl-diagnose.on.fleek.co/#/diagnose/access-content, https://cid.contact/)
  • present field and a button to tests if CID can be fetched from specific Peer (https://check.ipfs.network/)