fix(core): Always try to generate some kind of preview

[provokateurin]

Summary

Instead of providing the option to generate fallback previews this PR changes it to always generate some kind of preview if possible.
I don't see a reason why we shouldn't ever fallback to the mimetype or symbolic icon in case we are not able to generate a proper preview or it's a folder.
This also improves the UX, in case developers forget to manually request the mimeFallback, as now the users still see some preview.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[come-nc]

PHP changes are legit, but I do not know enough about this to judge the API change implied here.

[provokateurin]

The API change itself is backwards compatible, since the removed parameters are just ignored now. Any client still sending them will not notice that they are not used anymore.

[susnux]

The API change itself is backwards compatible, since the removed parameters are just ignored now. Any client still sending them will not notice that they are not used anymore.

It will change the behavior as you now get the 303 for the mimetype even if you do not request it.
Meaning for files e.g. you get a "preview" even if there is none and instead should display the inline svg.

Not sure if this is bad or not. But a safer approach would be to reduce this to only the folder mime type change.

[provokateurin]

It will change the behavior as you now get the 303 for the mimetype even if you do not request it.
Meaning for files e.g. you get a "preview" even if there is none and instead should display the inline svg.

You mean because a client would then chose to display it's own mimetype preview?
I get the idea, but feel like it is better to let the server handle this entirely.
Maybe @nextcloud/desktop, @nextcloud/ios and @nextcloud/android know if your clients behave this way and this change would result in unexpected behavior?

[susnux]

You mean because a client would then chose to display it's own mimetype preview?

Yes especially to get mimetype icons in the current color schema (dark / bright).