[core-client] Share state between ESM and CJS

[maorleger]

Packages impacted by this PR

@azure/core-client

Issues associated with this PR

N/A, follow up on #28631

Describe the problem that is addressed by this PR

If you are exporting both CommonJS and ESM forms of a package, then it is possible for both versions to be loaded at
run-time. However, the CommonJS build is a different module from the ESM build, and thus a different thing from the
point of view of the JavaScript interpreter in Node.js.

https://github.com/isaacs/tshy/blob/main/README.md#dual-package-hazards

tshy handles this by building programs into separate folders and treats "dual
module hazards" as a fact of life.

One of the hazards of dual-modules is shared module-global state.

In core-clientwe have a module-global operationRequestMap that is used for deserializing.
In order to ensure it works in this dual-package world we must use one of multiple-recommended
workarounds.

In this case, the tshy documentation provides a solution to this with a
well-documented path forward. This is what is implemented here.

Please refer to
https://github.com/isaacs/tshy/blob/main/README.md#module-local-state for added
//context.

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?

The obvious alternative is to just not do anything since tests have not been failing; however, that
seems risky. While this particular issue has not come up in tests, a similar one came up for core-tracing.

I am open to just not doing anything of course - I love not adding code so just give me a reason!

Checklists

• Added impacted package name to the issue description.
• Does this PR need any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here.)
• Added a changelog (if necessary).

[azure-sdk]

API change check

API changes are not detected in this pull request.

[xirzec]

LGTM