refactor(server): decouple generated images from image formats

[mertalev]

Description

The codebase currently hardcodes the formats of preview and thumbnail images, down to the thumbnail path being webpPath in the DB. This PR does two things:

1. Standardize the naming of generated images into preview and thumbnail without assuming their format
2. Change target image paths to have the type of the image in the name, e.g. asset-id-preview.jpeg and asset-id-thumbnail.jpeg
   • This is necessary to allow the same format for both types

These changes unblock future PRs to configure the target image format and support additional formats.

How Has This Been Tested?

Tested browsing, generating thumbnails, changing image resolution, running the migration job for the new image paths and installing and using a fresh app from the app store.

[cloudflare-pages]

Deploying immich with    Cloudflare Pages

Latest commit:	a367174
Status:	⚡️  Build in progress...

View logs

[danieldietzler]

There seem to be a lot of mess ups where GENERATE_JPEG_THUMBNAIL becomes GENERATE_THUMBNAIL and vice versa (I stopped looking for them when I hit media.service.spec) . I assume those aren't intentional changes?
Also, this is a breaking change, correct? The mobile app will break completely?

[alextran1502]

How is the current version on the app store of the mobile app behave with these changes?

[mertalev]

I'm not sure. I haven't tested mobile, but there didn't seem to be anything that relies specifically on the name of webpPath or resizePath.

[jrasm91]

I'm fine changing the internal usage, but the API changes are breaking changes and I had planned on moving these API calls to a media controller, so it would be a bit annoying to break it twice.

[mertalev]

The app seems to work fine for me with this PR.

[mertalev]

Coming back to this PR, is the concern here that it'll break third-party code? I suppose I could revert the DB / config file changes, leaving the renamed job names, enum names and adding -preview / -thumbnail to generated images.

[jrasm91]

I am fine with everything, including configuration changes, with the exception of the public facing server API changes. And only because I would love to migrate to a media controller with endpoints like /media/* and suggest that we implement the breaking API changes as new endpoints rather than updating the current ones. What do you think?

[mertalev]

I think the only API-facing change is renaming the DB columns. I think we could have the DTOs continue accepting the old names (marked deprecated) and map them internally, keeping the PR the same otherwise.

[jrasm91]

If there are no (breaking) changes to the open API spec file then I would say it is fine.

[danieldietzler]

Nice work! Quite hard to not mix it up all the time - both when reviewing and especially when migrating it I'd imagine 😅