Add support for sending bundled link previews (MSC4095)

[Raupinger]

Description

Closes #1547

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

AI disclosure:

• Partially AI assisted (clarify which code was AI assisted and briefly explain what it does).
• Fully AI generated (explain what all the generated code does in moderate detail).

[Raupinger]

the browser version is naturally limited by cors, but it works for sites that allow it (like https://bigrat.monster) and in tauri. Also theres the option to use ones homeservers preview endpoint.

[7w1]

I feel like fetching via homeserver should probably be the preferred default option here?

For unencrypted rooms the homeserver has the data anyway, making it the only place where there isn't really a privacy risk. Local fetching should be an opt-in backup in case someone's server doesn't allow previews, since it leaks the user's ip. For encrypted obviously neither option is truly privacy respecting, so they should just both be opt-in options.

I think sensible defaults would be something like:

• Opt out setting for generating bundles in unencrypted rooms
• Opt in setting for locally fetched previews for unencrypted rooms
• Opt in setting for homeserver bundles in encrypted rooms
• Opt in setting for locally fetched previews in encrypted rooms

And we prefer homeserver when enabled, otherwise fall back to local, otherwise no bundled media. Although that does seem like a lot of settings so not 100% sure

Also, yeah as mentioned in the todo, for locally fetched previews we definitely need some reliable way to prevent fetching local content, probably checking a/aaaa records and not follow redirects or something

[Raupinger]

Yea I hadn't considered that at all yet. All the small homeservers in my surroundings disable the preview endpoint (which is why im working on this in the first place), so I kinda just added the option to use it because the MSC makes that suggestion, with the main benefit I saw being circumventing the same-origin stuff.
Also I wouldn't consider local fetch to have much privacy impact in practice, most likely you've just visited the page you're sending a link to anyway. (although ig for unencrypted rooms "low impact" is still worse than "literally no impact")

I think what might be best is that there's a dropdown for unencrypted rooms and encrypted rooms each that has "try both", "homeserver only", "local only", and "disabled". That way its just two settings. We can bikeshed the order "try both" tries them, but doing homeserver first would be fine by me. Defaulting unencrypted rooms to "homeserver only" and encrypted rooms to "disabled" seems reasonable as well.

[lunar-seal]

In my opinion, 7's suggestion for the settings seems more intuitive. Defaults are pre-ticked boxes.

A drop down hides it's options.

I think homeserver should be tried first.
The website may be slow and it's additional load on the website.
The homeserver is something the users trusts, is currently up bc you couldn't use sable otherwise, and controlled by the user.