Reduce dependencies on g/g

[unmarshall]

How to categorize this issue?

/area dev-productivity
/area open-source
/kind technical-debt

What would you like to be added:

• Except ImageVectorOverride all other places where we are using g/g utilities should be removed.
• Add constants.go in etcd-druid API and move the reconcile annotation key there. Rename the reconcile annotation key and to maintain backward compatibility continue to support the current reconcile annotation key name.

Why is this needed:

gardener is a mono repo and adding it to the go mod dependencies brings in truck load of dependencies which are not really needed in etcd-druid. We only use utilities from gardener/gardener code base and many of which are very simple ones as well which do not require the entire weight of g/g code base to be added into go mod dependencies.

[shreyas-s-rao]

Meeting minutes from out-of-band discussion between myself, @unmarshall and @timuthy :

1. Etcd-druid depends on g/g, which brings in a lot of unnecessary dependencies such as machine-controller-manager, vpa, helm, etc which are never used by etcd-druid. By removing dependence on the gardener/gardener module, the druid binary which is currently 69MB large, can be reduced to 51MB (a reduction of 18MB), and a removal of 30 modules from the go.mod is seen.
2. Most of the dependencies of etcd-druid on gardener/gardener are related to utilities, and can be easily replaced.
3. The concept of image vectors is not just a utility, but a contract between gardener and etcd-druid, with a specific API on how to consume the feature. While etcd-druid can redefine this within its code, if the API changes in the future, then g/g functionality breaks.
4. @unmarshall and I wanted to know whether the imagevector package can be moved into its own go module or repository, so that druid can depend only on this and not pull the entire g/g dependency.
5. @timuthy mentioned that the image vector package is largely stable, and has been for a long time, and can give some thought to move it into its own go module, and possible go workspaces for ease of development.
6. In the meantime, he suggested that we copy over the imagevector package code to druid on a temporary basis, so that we can get rid of the g/g dependency. We can possible have a hack script that copies the latest version of the code from g/g upon make generate, so that druid stays up-to-date with the latest changes in g/g. This will be in place until there is a decision on how to handle imagevector package in gardener/gardener repo.