fix(mobile): revert cache fixes

[alextran1502]

• Revert "fix(mobile): use immutable cache keys for local images (fix(mobile): use immutable cache keys for local images #17736)"
• Revert "perf(mobile): remove small thumbnail and cache generated thumbnails (perf(mobile): remove small thumbnail and cache generated thumbnails #17682)"

[alextran1502]

@EinToni @lukaszwawrzyk

During my test round for release, I identified issues when the two PRs are combined.

1. When navigating to the Backup Page > Album Selection, clicking on the button to view the assets in the album displays the same asset thumbnail for all assets.
2. After scrolling the timeline up and down, then entering the detail view to view local assets, swiping left and right a couple of times. I then sign out and sign back in the same instance with a different account. The cached thumbnail is now displayed incorrectly, as in showing the thumbnail of a different asset rather than the one it should represent.

I think this issue will take some time to investigate and come up with the right solution, so I revert these two PRs to prepping for the release

[lukaszwawrzyk]

@alextran1502 That's interesting. Is it confirmed that 2 PRs conflict cause problems together or it might just be that only one of them is problematic?

[alextran1502]

@lukaszwawrzyk they caused the two issue I describe. Your PR caused the issue with the thumbnails render the same asset in the album selection view, and the other with a custom cache implementation caused issue of incorrect thumbnail displayed

[EinToni]

@alextran1502 Can it be can the local id of an asset can be equal on two accounts? So Image A could have the local ID 001 on account X and Image B has also the local ID 001 but on account B.
That would explain the behavior, as the key for the cached thumbnails is "localID_{width} x{height}".

[alextran1502]

@EinToni This is on the same device, so yes, the localId should be similar on both accounts. And it should refer to the same asset

I reimplemented the mechanism but without a custom cache and it seems to work well as well #17787

[EinToni]

@alextran1502 It would be great to have to actual functionality with the caching. If you can wait until tomorrow I would he happy to open another PR with my changes and the caching key adapted to use the user id as well. Then this behavor will be fixed.

[alextran1502]

@EinToni I am planning for a release tomorrow afternoon CTS timezone. If you can put it in before that, I can help with testing

[EinToni]

@alextran1502 Okay thank you I opened another PR with the respective changes. I'm in UTC+2 so I'll go to bed now, but will do all I can to get this merged tomorrow :D

[lukaszwawrzyk]

@alextran1502 #17794 I fixed my PR too, I tested my scenario and scenario that you reported as broken and it seems to work fine.