normalize NCID by stripping Swift prefix

[rbtr]

Reason for Change:

#1767 introduced a bug where, if the NC in state does not have the Swift_ prefix, when we unconditionally add the prefix we become unable to identify it in the NMA responses which don't have it and are stuck:

{"httpStatusCode":"200","networkContainers":[{"networkContainerId":"de043d23-a135-401c-b6a8-1ab6a09f980a","version":"0"}]}

and yet

[Azure CNS] Failed to get NC de043d23-a135-401c-b6a8-1ab6a09f980a doesn't exist in NMAgent NC version list Skipping GetNCVersionStatus check from NMAgent

After investigating, this it seems like nobody knows where or even if we actually have NCs in the wild with the Swift_ prefix, but it is possible that we do as a legacy artifact, and it could be unsafe to remove the prefixing entirely.

However, for the purposes of the lookup in the NC version list query, we can strip the prefix when add items to this in-memory map, and strip prefixes when we attempt to look objects up in the map, and unstick ourselves. This additional prefixing is not done anywhere else, and no usages of these objects escape this local map, so it should be safe and back-compat.

Issue Fixed:

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• relevant PR labels added

Notes:

[timraymond]

Part of me wants to encapsulate all that NCID wrangling into some type or function that just contains the knowledge of wrangling prefixed and non-prefixed keys... but this does seem pretty isolated, so I'm okay with it. If we do anything more in this space though, I think it will become worth it.

[rbtr]

I agree. I went this way because maybe it's possible on extant deployments to have Swift_ prefixed NCIDs in CNS internal state (on disk) or in the communication path from DNC (existing CRD definitions). Finding all the data boundaries where those need to be transformed would blow this up into a much bigger change 🙁
I think we'll have to try to do that as a non backcompat change in the future and leave any old defs behind.

[rbtr]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).