[WIP] feat: file conversion provider

[elzody]

• Part of: 📄💫 File conversion #49603
• Front: feat(api): File conversion Files action #50123

Summary

This PR will introduce a file conversion API endpoint, which can be called to convert a file from one type to another. Apps can register their own conversion providers (which implement IConversionProvider), and the providers can define which MIME types they support for conversion via ConversionMimeTuples.

TODO

• OpenAPI specs
• Flesh out some more details around the IConversionProvider interface
  • What type should it really return? Stream, resource, File, file path?
• What should happen when multiple apps register similar conversion providers?
• How should we make the preferred list of conversion providers?

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)

[juliusknorr]

Something just came to my mind is that for integrating the user interface we may also want additional metadata for the target formats.

We can probably get the file extension from our mimetype mapping, but wondering if we need to have more details, like a display name. Similar to save dialogs that came to my mind:

[juliusknorr]

@sorbaugh Has the files team already discussed any UI parts with designers? I'd say we can start with this PR and could extend/adapt on demand later on as well.

[skjnldsv]

Ah, I literally added a similar comment eheh

Two options I think:

1. We stop using getSupportedMimeTypes and go back to a singular getSupportedMimeType, and we basically use the name, only one Provider per destination mime
2. We turn this into a mime => l10n array, so we know the end name of each mime :)

[skjnldsv]

Maybe also check the parent folder CREATE permissions?

[elzody]

This is a good point. I just did some testing by sharing a view-only folder with a document in it to another user, and it will already throw an OCP\Files\NotPermittedException if it cannot write to the destination (L122), which then returns something like this in the network response via an OCSException:

{
  "ocs": {
    "meta": {
      "status": "failure",
      "statuscode": 999,
      "message": "Could not create path \"/alice/files/Bobs_Shared_Folder/converted_file.pdf\""
    },
    "data": []
  }
}

I can still implement an explicit check if necessary, though. What do you think? It could also be that my error handling here isn't the best or obvious enough.

[skjnldsv]

I can still implement an explicit check if necessary, though

I am usually in favour of clear sanity checks.
Because if something breaks/changes in the following methods, we'll have no way of knowing it.

[skjnldsv]

Why is this needed?

I think the name of the end format is more relevant.