[lib] Exclude users that don't support thick threads from results

Summary:
When a user can't be added to thick thread, they shouldn't be included in search results.

https://linear.app/comm/issue/ENG-9257/limit-chat-candidates-to-users-who-are-registered-with-identity

Depends on D13404

Test Plan: Checked that the user who don't support thick threads aren't shown in add member modals of thick threads.

Reviewers: kamil, will

[lib] Create a thin thread when some users don't support thick threads

Summary:
Check if all the users support thick threads and chose thread type accordingly.

https://linear.app/comm/issue/ENG-9257/limit-chat-candidates-to-users-who-are-registered-with-identity

Test Plan: On both native and web checked if the correct thread type is created, when sending text message, depending on the presence of members in `AuxUserStore`

Reviewers: kamil, will

[lib] Add reducer and action to store established holder

Summary:

First action from [[ https://linear.app/comm/issue/ENG-9285/implement-holder-store-actions | ENG-9285 ]]. Addresses [[ https://linear.app/comm/issue/ENG-9286/add-established-holder-to-the-store-in-useblobserviceupload | ENG-9286 ]].

Added reducer for holders and action to store already-established holder in the store.
We use it in the blob service upload hook, to store the initial holder, which previously was forgotten

Inspired by D12949

Depends on D13401, D13402

Test Plan:

- Reducer unit test
- Uploaded multimedia to a DM thread and used Redux Devtools to ensure the action was performed correctly

Reviewers: kamil, tomek

Subscribers:

[lib] Create Redux store for blob holders

Summary:

Address [[ https://linear.app/comm/issue/ENG-9280/create-redux-store-for-holders | ENG-9280 ]].
Created a store for blob holders

Created initial version of the holder store. Inspired by D12936

Test Plan:

Native and web:
- Logged out and in before applying this diff. Stayed logged in.
- Applied this diff
- Restarted app to make sure the migration was successful

Native log:
```
 LOG  redux-persist: migrationKeys [83]
 LOG  redux-persist: running migration for versionKey 83
 LOG  redux-persist/stateReconciler: rehydrated keys 'navInfo, currentUserInfo, entryStore, messageStore, calendarFilters, dataLoaded, customServer, alertStore, watchedThreadIDs, enabledApps, reportStore, globalThemeInfo, deviceCameraInfo, userPolicies, keyserverStore, localSettings, threadActivityStore, communityStore, tunnelbrokerDeviceToken, queuedDMOperations, _persist, holderStore'
```

Reviewers: kamil, tomek

Subscribers:

[lib] Prefix blob holders with device ID

Summary:

Address [[ https://linear.app/comm/issue/ENG-9282/make-holders-prefixed-by-device-id | ENG-9282 ]].
Made multimedia blob holders prefixed by device ID.

Device ID is a base64-like string, which [[ https://github.com/CommE2E/comm/blob/aae90ac4b5b98e6c53a8117ac14216199c3df058/shared/comm-lib/src/tools.rs#L146 | isn't a valid holder ]] so used base64url conversion.

Test Plan:

Successfully uploaded multimedia to a DM thread. Printed the

Reviewers: kamil, tomek

Subscribers:

[lib] Avoid unnecessary sets creation

Summary:
We don't need to create sets for the queues - we can as effectively check the object keys. The benefit of the new approach is that we don't perform a linear amount of work when new entities appear.

Test Plan:
1. Created an operation with a reaction that was received before an operation creating the message
2. Created an operation with an entry edit that was received before an operation creating the entry
3. Created an operation with thread subscription change that was received before the user became a member

In each of the cases verified that the result was correct and that the operation was removed from the queue.

Reviewers: kamil, will

[lib] action for calling fetch all communities with names endpoint

Summary: we'll dispatch this action to call fetch_all_communities_with_names on the authoritative keyserver

Depends on D13398

Test Plan: dispatched action using useLegacyAshoatKeyserverCall. see gist: https://gist.github.com/vdhanan/df461cabc7a954ab1bc169104b98fbbb

saw success in redux and the correct payload

Reviewers: ashoat, tomek

Subscribers:

[lib][keyserver] new endpoint to get all community infos with names

Summary: endpoint corresponding to responder in D13397

Depends on D13397

Test Plan: tested at end of stack by calling endpoint from web

Reviewers: ashoat, tomek

Subscribers:

[keyserver] new responder function to fetch all community infos with …

…names

Summary: returns an object instead of an array and checks if the viewer is logged in

Depends on D13396

Test Plan: tested at end of stack by calling responder successfullly from web

Reviewers: ashoat, tomek

Subscribers:

[keyserver] new fetcher to get all communities

Summary:
we need the community id, name, and farcaster channel id for all communities so we can display them to users in a modal.

part of https://linear.app/comm/issue/ENG-9216/new-keyserver-endpoint-to-get-a-list-of-communities

Test Plan: tested the SQL query directly on my local mariadb instance. will test further in subsequent diffs that call the keyserver endpoint that returns this data

Reviewers: ashoat, tomek

Subscribers: