Jts/2006 improve search

[JohnSimonsen]

Ensure there are no UI leakage of memberinfo in searches in SpotLightDialog / InviteDialog

• Added a new feature flags:

  • showRoomMembersInSuggestions
    • true - Use Elements own suggestion logic, using all room memberships/space memberships as suggestions.
    • false - exclude suggestions, and use mostly search results to populate Suggestions.
  • showRecentsInSuggestions
    • true - User Element default logic for displaying "Recents" in InviteDialog
    • false - exclude "Recents" in invite dialog

• It should not worsen the security/privacy, as the filtered recents should only be users you already share a DM with

• If we don't allow "recents" I think we should consider create our own cache / some other solution

  • As it is bothersome to "have" to search, in order to select a member you wish to invite to a room.

Notes for later

• Initially attempted to make the suggestions adhere to our business logic.
  • Some code from these attempts still in effect, as a security fallback / future use (SortMembers.ts buildMemberScores
  • Experimented with "building" a roomlist based on rooms tagged with "app.verji.tenant_nfo"
    • Was very ineffective because in order to check if a room has tag, we must call the async method cli.getStateEvent() which uses a synapse endpont to get the tag/info. Which will spam the server when iterating through all the rooms
    • A better solution would be to create a seperate endpoint to get the roomIds which are relevant in tenant for user.

While developing I also did extensive testing of the Business logic, our Custom User Search, and frontend to make sure the following:

Some changes required in backend, usersearch in order to solve the discrepancies, from expected result. As we in frontend, "trust" the search results fully.