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).

[provokateurin]

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

IMO this should be a parameter and then the server would return the correct one.
Not sure if it is necessary and feasible though.

[mgallien]

desktop files client would be fine and was not using the 2 removed arguments
that may make some of our code obsolete (we were manually redirecting the client to fetch the mime type icon from server when needed)

[susnux]

IMO this should be a parameter and then the server would return the correct one. Not sure if it is necessary and feasible though.

This is another issue and much harder, as we in general need to discuss how to proceed with icons.

[provokateurin]

This is another issue and much harder, as we in general need to discuss how to proceed with icons.

Agreed, there are a bunch of problems with how we currently deal with icons. Maybe something to discuss in the Files Team Hack week ;)