feat(calling): U2C catalog cache logic

[Kesari3008]

COMPLETES #https://jira-eng-sjc12.cisco.com/jira/browse/CAI-6513

This pull request addresses

We are storing the U2C catalog for 24 hours to avoid fetching it if frequent browser refresh occur.

by making the following changes

Change Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tooling change
• Internal code refactor

The following scenarios were tested

Refreshed browser and observed in the network that U2C request was not being fetched anymore if entry in cache is found.

The GAI Coding Policy And Copyright Annotation Best Practices

• GAI was not used (or, no additional notation is required)
• Code was generated entirely by GAI
• GAI was used to create a draft that was subsequently customized or modified
• Coder created a draft manually that was non-substantively modified by GAI (e.g., refactoring was performed by GAI on manually written code)
• Tool used for AI assistance (GitHub Copilot / Other - specify)
  • Github Copilot
  • Other - Please Specify
• This PR is related to
  • Feature
  • Defect fix
  • Tech Debt
  • Automation

I certified that

• I have read and followed contributing guidelines
• I discussed changes with code owners prior to submitting this pull request
• I have not skipped any automated checks
• All existing and new tests passed
• I have updated the documentation accordingly

---

Make sure to have followed the contributing guidelines before submitting.

[aws-amplify-us-east-2]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-4569.d3m3l2kee0btzx.amplifyapp.com

[Coread]

There are a number of issues here:

1. The preauth catalog is always assumed to be the same, regardless of the user. But this is not the case. You can get a different catalog due to proximity (e.g. VPN/no VPN) and entering a different email will also result in a different catalog
2. After auth, the assumption that the same org means the same catalog is also not the case. Orgs can have users on different clusters and so get different catalogs
3. This code is written in services v1, when we are moving soon to services v2.
4. The code references local storage directly. In the SDK we use either bounded or unbounded storage, letting the consumers of the library choose then how to actually store the data.

[Kesari3008]

There are a number of issues here:

1. The preauth catalog is always assumed to be the same, regardless of the user. But this is not the case. You can get a different catalog due to proximity (e.g. VPN/no VPN) and entering a different email will also result in a different catalog
2. After auth, the assumption that the same org means the same catalog is also not the case. Orgs can have users on different clusters and so get different catalogs
3. This code is written in services v1, when we are moving soon to services v2.
4. The code references local storage directly. In the SDK we use either bounded or unbounded storage, letting the consumers of the library choose then how to actually store the data.

Thanks for the review @Coread. This PR is raised with changes in order to check the feasibility of this solution so once we have the approval on approach we will replicate the changes on v2 catalog as well. Also was facing some issues with bounded storage to get the review started but plan is to use boundedStorage only. I will be making those changes in this PR itself

Now for 1st and 2nd point, I will address those points. Could you please help me identify in what all cases the catalog changes or redirect me to where I can find this information. So I can consider all the cases here

[chrisadubois]

I do not recall having changing the concept of how we handle u2c catalogs. We rely pretty heavily on the fact we will always get a fresh u2c catalog. In fact, as part of the u2cv2 migration, we are not handling the failsafe hostmap because we have no cache for the u2c catalog. This changes us to follow the behavior of what the native client does, and that has some drawbacks that impact the application.

Also, this seems like the wrong approach, opens a bigger can of worms than it resolves. Perhaps the root issue is that the API is slow? IMO this is high risk low reward

[chrisadubois]

Please make this change a configuration initialization option.

[Kesari3008]

Closing this one, Will raise new PR with changes applied only for calling based on config passed