[net-8411] bug: fix premature token and service instance deletion due to pod fetch errors

[ndhanushkodi]

Changes proposed in this PR

• When a pod fetch fails, we used to not add it to the endpointAddressMap resulting in it getting deregistered and its token deleted.
• This PR makes the cases we deregister in more explicit-- only if the pod does not exist, we will deregister the service instance and delete the token. This PR also switches endpointAddressMap to a map that marks endpoints explicitly for deregistration (or not). And only entries explicitly marked in the map for deregistration are deregistered.

How I've tested this PR

Unit tests, Manually testing by changing the code to simulate pod fetch errors and with the fix in this PR it doesn't deregister the instance and delete the token

How I expect reviewers to test this PR

Checklist

• Tests added
• CHANGELOG entry added

[DanStough]

One blocking question about the deregister function.

[DanStough]

Don't we want to return true if it's not in the map, like in the case an service instance no longer appears in the endpoints subset?

[ndhanushkodi]

Thanks for this-- I intended the change to be that only if you explicitly add the address to the map for deregistration then you should deregister, but I think there's too many cases where we do rely on the implicit deregistration when a service instance no longer appears in the endpoints, and a bunch of tests were failing. So I just changed the logic to be very specific to the pod-fetch-error case, so only if there is a k8s api related pod fetch error, we explicitly choose to add it to the map and say "don't deregister this", and now the deregister function does return true if it's not in the map!

[DanStough]

LGTM! Just one non-blocking note about the changelog.

[DanStough]

I think this might be a copy-paste error from the other PR; we want something specific here, right?

[ndhanushkodi]

LOOL yes thanks!