fix(mobile): 14983 Images upload to shared album with common name

[Tyris]

This PR should address #14983.

The issue is caused because the client just asks for the first album with the matching name - which can result in the shared folder being returned.

The methods in question should never be uploading to an album owned by someone else, so setting shared to false in these cases should work (assuming I understand "shared" correctly - ie: that the item is shared with me).

Above assumption was wrong - have used ownerId instead.

Testing performed:

• Old code (reproduce issue)
  • Create a new user with an album called "Test" and share that to my original user
  • Use the original user to upload an album called "Test" using the "Sync albums" option
  • Verify that files end up in the wrong album ✅
• Using fixed code (verify fix)
  • Using the new user, create an album called "Test2" and share that to my original user
  • Use the original user to upload an album called "Test2" using the "Sync albums" option
  • Verify that a new album was created and images are not synced to the wrong album ✅
• Using fixed code (verify edge case)
  • Using the original user, create an album called "Test3"
  • Use the original user to upload an album called "Test3" using the "Sync albums" option
  • Verify that the images go to the correct existing album ✅

Other notes:

• Messing around with creating/deleting folders and adding to them can cause pretty weird issues because the "album exists" check is done locally; so if the albums aren't synced it will result in creation of a new album with that same name. This was apparent when creating new albums remotely and then immediately doing a sync for an album with the same name on the client - a new album would be created causing a duplicate (yuk!)

  In general, the sync system seems to be a little unreliable across these types of cases... Not sure the best long-term solution - a unified storage engine that handles remote and local through a single interface (think Firebase RTDB) would probably be the cleanest... I tried forcing an remote album refresh before adding assets, but this was non-trivial and expensive.

• Related to my investigation of the above, the refreshRemoteAlbums() call has some strange logic that "works" but isn't really what was intended when written.

  Using getAll(shared: true) gets all shared albums the user can access (regardless of owner, despite the previous comment stating "owned if isShared is false)).

  Using getAll(shared: null) gets all albums (incuding shared = true and shared = false).

  I presume the intent here was to get albums that were shared to me (but not owned by me), and not shared (ie: mine), but the logic is way off since (because shared is set to null, instead of false; but also because shared doesn't actually do this!). It also just then combines them - so makes more sense to just get them in a single call.

  Have simplified this code to do what it should do (without the confusing bits) - would appreciate feedback on this commit in particular: 979ce9

[alextran1502]

Hello, can you write a few words in the PR's description on how you tested this?

[Tyris]

Hello, can you write a few words in the PR's description on how you tested this?

Have updated now that I've had a chance to test. My initial assumption that "shared" means "not mine" was wrong - but I'm not the first person to make this mistake D:

Would appreciate some feedback on my other notes above :)

[alextran1502]

Thank you. I will take a look at this in the coming days