[feature] Media attachment placeholders

[tsmethurst]

Description

If this is a code change, please include a summary of what you've coded, and link to the issue(s) it closes/implements.

If this is a documentation change, please briefly describe what you've changed and why.

This pull request makes the following changes:

1. When it's not possible to download and process media from a remote instance that's attached to a status (temporarily unavailable, media too large, type can't be processed), don't throw it away, but instead store the media attachment as unknown type in the database, without caching the data in storage.
2. When serving a status with unknown media attachments via the API, remove the attachments from the API model representation and replace them with a note from the instance linking to the attachments directly.
3. When serving a status with unknown media attachments via the web, use "external link" placeholders.

Cache of unknown media types will be reattempted next time the status to which the media is attached gets refreshed (2hr cooldown). This means that as we add support for more types, it will be possible to refresh old statuses and have the new media show up properly.

The note added to the status when serialized via the API uses the html <aside> tag to indicate that this is supplementary information:

<aside>
   <p>Note from your.instance.com: 2 attachments in this status could not be downloaded. Treat the following external links with care:
      <ul>
         <li><a href="http://example.org/fileserver/01HE7Y659ZWZ02JM4AWYJZ176Q/attachment/original/01HE7ZGJYTSYMXF927GF9353KR.svg" rel="nofollow noreferrer noopener" target="_blank">01HE7ZGJYTSYMXF927GF9353KR.svg</a> [SVG line art of a sloth, public domain]</li>
         <li><a href="http://example.org/fileserver/01HE7Y659ZWZ02JM4AWYJZ176Q/attachment/original/01HE892Y8ZS68TQCNPX7J888P3.mp3" rel="nofollow noreferrer noopener" target="_blank">01HE892Y8ZS68TQCNPX7J888P3.mp3</a> [Jolly salsa song, public domain.]</li>
      </ul>
   </p>
</aside>

---

Screenshots of a status reply containing one processable type and two unknown types.

On the web:

On pinafore (note, the testrig instance is localhost:8080):

---

closes #1013
closes #2175

Relates to (and partially addresses) #2313
Relates to (and partially addresses) #2308

Checklist

Please put an x inside each checkbox to indicate that you've read and followed it: [ ] -> [x]

If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).

• I/we have read the GoToSocial contribution guidelines.
• I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
• I/we have performed a self-review of added code.
• I/we have written code that is legible and maintainable by others.
• I/we have commented the added code, particularly in hard-to-understand areas.
• I/we have made any necessary changes to documentation.
• I/we have added tests that cover new code.
• I/we have run tests and they pass locally with the changes.
• I/we have run go fmt ./... and golangci-lint run.

[NyaaaWhatsUpDoc]

very excited for this one tbqh 👀

[tsmethurst]

@NyaaaWhatsUpDoc Ready to review now I reckon!

[filipesmedeiros]

@tsmethurst Phanpy's dev suggested using a <small> tag instead of an <aside> since browsers style it a bit differently by default. Also, using the media_attachments field on the post? I don't know enough about the backend of Mastodon/GtS to immediately know what that means but you might!

cheeaun/phanpy#365 (comment)

This issue is mostly because right now the text of this placeholder is very easily confused with the actual text of the post itself (happened to me).

[xmgz]

yes, some kind of styling would be useful.

Also, I don't know if it is possible to add a reason for the attachment not loading (explicit or an error code), so I could blame the poster and not my GtS instance 😸

thank you