feat(webex-core): hostmap interceptor

[Coread]

COMPLETES SPARK-555022

This pull request addresses

The hostmap from u2c maps the logical name of the service (these are actually FQDNs) to the hosts. Until recently, the first host listed for each logical name was the same as the logical name. Going forward this will not be the case. Services will continue to use logical names i.e. conversations/locus and the client needs to replace these with the correct host.

Existing methods in webex-core/services do not handle this (e.g. getServiceFromUrl)

by making the following changes

I've created a new method replaceHostFromHostmap which looks up the host in the hostmap and replaces it in a supplied URI. I've used this new method in an interceptor, so it will automatically happen for each request.

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 where tested

I've tested this in integration and production. Currently, the hostnames are the same so there is no effect, but I verified that the code was running through the new interceptor and selecting the host.

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-3789.d3m3l2kee0btzx.amplifyapp.com

[sreenara]

@Coread can you please fill in the manual tests you've done in the PR description test section? It would be good to see the real-world implication of this interceptor.

I see that we're replacing the hostname with the first instance that we find in the hostmap. Just for my understanding, what happens when the request fails to the first hostname and we need to use the second entry that's found in the hostmap? Do we plan on adding any logic for this at a later time?

[Coread]

@Coread can you please fill in the manual tests you've done in the PR description test section? It would be good to see the real-world implication of this interceptor.

I see that we're replacing the hostname with the first instance that we find in the hostmap. Just for my understanding, what happens when the request fails to the first hostname and we need to use the second entry that's found in the hostmap? Do we plan on adding any logic for this at a later time?

This is logic that already exists in the desktop apps and has done for many years, the original intention of which was to provide high availability. The U2C hostmap will always contain at least one entry in the hosts section. All the entries will have the same host, but with different ids. See the below screenshot. i.e. the high availability feature of the catalog was never completed, so there is no point in using it like that, no point in checking other hosts.