Rename KeyType and JsonWebKey to avoid conflicts with predefined types

[maorleger]

When upgrading API Extractor we noticed that KeyType and JsonWebKey defined in KV Keys conflict with the same names in dom.lib.ts which causes them to be renamed as KeyType_2 and JsonWebKey_2 in the API view.

To avoid this conflict, we can rename them locally but still export the conflicted name as deprecated alias.

Open questions:

1. What should we rename these to
2. What should we do with other names such as KnownKeyTypes? Rename them as well?

Created as a result of https://github.com/Azure/azure-sdk-for-js/pull/17702/files#r709589284

[xirzec]

I feel like this is, similar to a new lint check, finding a problem that we have today. I would prefer to never shadow a global type in the runtime environments we support if we can avoid it.

That said, it's not hard for consumers to alias our poor names to something unambiguous.

[ramya-rao-a]

Before taking this up, I would be curious to do a sweep across all our packages and collect other such references to get an idea of the extent of this problem

[maorleger]

Just a note that this and #17721 are very closely related - in JS's case there's no serialization really and the only difference between our JsonWebKey and the built-in is that we use keyOps instead of key_ops. Other languages have more differences but for us it might be as simple as deprecating keyOps (but not removing it until the next major) and starting to use key_ops.

[github-actions]

Hi @maorleger, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.