feat(attachments): Add support for changed API due to introduction of snowflake ids in server

[DerDreschner]

The underlying server is introducing snowflake ids. This means that the API will change when using them (id will be from type string in the future, instead of int).

Although we don't use them right now, there were some breaking changes in the entity model (that are going to be reverted partially). As we have to use them in the future anyway, I think it's a good idea to merge the changes from this PR anyway to be a bit more prepared.

[DerDreschner]

I've initially made some refactoring changes (newFile() accepts the content since v19, which means the separate putContent() calls are obsolete and handling/declaring some more exceptions that are not handled/declared right now). But when changing the failed unit tests, I realized that should be handled separately. 😄

[ChristophWurst]

Let's wait for nextcloud/server#57442, after which the changes shouldn't be necessary.

What we definitely have to adjust right now are any usages of a file id or similar table where the primary key was actually migrated to a snowflake.

Our own tables, which don't use snowflakes, shouldn't be affected right now.

[DerDreschner]

I think we're not affected by any other changes beside the ones that will be reverted in nextcloud/server#57442. No tables get converted automatically, which means our own tables are fine for now. Aside from them I'm not aware of any other tables we're currently access/use? Or what do you mean with file id?

Just don't want to do anything wrong or missing any task for myself. 😅

[ChristophWurst]

File id refers to primary keys pointing to oc_filecache table but also the new previews storage :)

[DerDreschner]

I'll have a closer look into it next week with a fresh mind. But I don't think there is anything to do for us as I were not able to find any API changes yet. :) The list of places I've checked will be posted here then.