chore:[#186705729] add query find user by business name

[aadedejifearless]

Description

This PR introduces a new feature to search for users by their business name using a query in AWS DynamoDB. The approach involves creating an SQL query statement in the DynamoUserDataClient that searches for users with businesses. The query checks for the existence of businesses and ensures that the businessName field is not missing.

Once the query is executed, the results are ingested into the DynamoDataClient. There, the business names are normalized (trimmed and converted to lowercase) to ensure case-insensitive matching when filtering for users with a business name that matches the search term.

Ticket

This pull request resolves #186705729.

Approach

• Added queryUsersWithBusinesses in DynamoUserDataClient to execute a DynamoDB query that retrieves users with businesses.
• Implemented findUserByBusinessName in DynamoDataClient, which filters users based on a normalized, case-insensitive business name.
• Also updated the Router tests where the mock/stub DynamoDataClient lives as well as the Batch files where the mock/stub DynamoUserDataClient lives.

Steps to Test

1. Run Unit Tests
   The following tests were created to verify the functionality of the changes here and previous existing logic in the DynamoDataClient.

• should find user by businessName ...: This test ensures that the findUserByBusinessName method filters users correctly by matching business names, including case-insensitive matches.
• should migrate data for multiple users with outdated versions...: This test verifies the migration of outdated user data, ensuring the business data is updated and logged appropriately

2. Run the test suite with yarn test and ensure the tests pass successfully.

Notes

Code author checklist

• I have rebased this branch from the latest main branch
• I have performed a self-review of my code
• I have created and/or updated relevant documentation on the engineering documentation website
• I have not used any relative imports
• I have pruned any instances of unused code
• I have not added any markdown to labels, titles and button text in config
• If I added/updated any values in userData (including profileData, formationData etc), then I added a new migration file
• I have checked for and removed instances of unused config from CMS
• If I added any new collections to the CMS config, then I updated the search tool and cmsCollections.ts (see CMS Additions in Engineering Reference/FAQ on the engineering documentation site)
• I have updated relevant .env values in both .env-template and in Bitwarden

[seidior]

Something I forgot to mention in the review of the last DB split ticket: is there anything in the new business structure that points back to the UUID of the user? This may make the work in this ticket a bit easier, since you in theory would just be able to query the secondary index for business names on the businesses table, get the business data, then have the UUID of its owner, and return that object.

[seidior]

[boulder] How will this work when business data is no longer inside user data?

[aadedejifearless]

Currently, the workflow relies on business data being inside the user data structure. In the planned migration, we will remove the businesses object from userData and make slight updates to the code.

We will introduce a GSI (currentBusinessId), the common field between the users and businesses tables. The updated flow will:

• Query the businessesTable to find businesses by name with fuzzy (matching: this is now implemented in the current state).
• Extract the currentBusinessId from the matched business.
• Query the usersTable using currentBusinessId to find the associated users.
  let me know your thoughts @seidior . this also answers your previous questions on what field do we have that ties both user and businesses currently.

[seidior]

To sum up what we discussed in our meeting just now:

• The current migration for splitting out users and businesses and keeping them in sync should be modified (or a follow-up migration should be added) so that, in addition to a version field being added to the business record, we also add a field that is called something like "owningUser" that is the UUID of the user data record.
• We then can modify this work to use the secondary index for business names on the businesses table to find the corresponding business record, then use this "owningUser" field in the business record to get the user data and return that.
  • This means we don't have to search through all businesses of all users for the correct user data, we just have to find the fuzzy-matching businesses and return those user data objects. This should vastly speed up the performance of this endpoint.