RestMapper cache is never invalidated when a client requests a group without specifying a version

If a client requests a mapping for an API group without specifying the version, the current code will always rely on findAPIGroupByNameAndMaybeAggregatedDiscoveryLocked to retrieve group resources using aggregated discovery.

But since this function looks at the apiGroups cache first, once an apiGroup has been discovered, its resources will never be updated. If some CRDs that declares new versions for an existing group are installed after this initial lookup, subsequent calls to mapper.RESTMapping("newKind") will continuously fail.

This has been observed in sylva project that uses flux kustomize controller. It sometimes fails to perform healthChecks on some resources and continuously returns a NoMatchError, whereas the CRD is installed for a while in cluster (see flux issue). Kustomize controller relies on kstatus library to perform healthCheck on resources, and that library does not provide any version while calling mapper.RESTMapping.

Start by locating findAPIGroupByNameAndMaybeAggregatedDiscoveryLocked and the apiGroups cache, then trace calls from mapper.RESTMapping when no version is supplied. Reproduce the sequence with an initial lookup followed by installing a CRD that adds a version, and verify the mapper refreshes resources instead of returning NoMatchError.