[deps][breaking] Upgrade controller-runtime to v0.20.1

[shadialtarsha]

Closes #12

💸 TL;DR

• Updating controller-runtime to version v.0.20.1
• Removing WatchesRawResource - breaking change.

📜 Details

Due to the recent breaking PRs on controller-runtime kubernetes-sigs/controller-runtime#2799 and kubernetes-sigs/controller-runtime#2783, I had to make some decisions and I would appreciate your inputs on it:

1. Replace WatchesRawSource with two new builder functions: WatchesChannel and WatchesKind because you cannot create a raw source.Source anymore.
2. Thus, we cannot do WatchesRawResource anymore because we cannot wrap the handler with our own observer.
3. Switch all the RateLimiter functions to be typed.

🧪 Testing Steps / Validation

I replaced the SDK on my Ingress Controller and things look like they are working. I will do more tests as well to make sure we are good.

✅ Checks

• CI tests (if present) are passing
• Adheres to code style for repo
• Contributor License Agreement (CLA) completed if not a Reddit employee

[harveyxia]

Some minor comments + we should think about reworking the WithChannels builder option because channel sources' value is that the events could originate from anything, not just Kubernetes object events, so we should avoid constraining the channel to client.Object.

One possible approach is to generify WithChannels to WithSources and allow callers to pass in arbitrary sources. Illustrative code here

[harveyxia]

Out of curiosity, why was this introduced? Is 1s too long of a base delay for certain use cases?

[shadialtarsha]

Check this out

achilles-sdk/pkg/fsm/handler/observed_event_handler_test.go

Line 245 in 57f66b1

assert.Equal(t, queue.Len(), len(tc.expectedLogs))

The current in production workqueue.DefaultControllerRateLimiter() has no delays what so ever, so tests were passing. However, the new DefaultControllerRateLimiter has an initial delay causing the tests to fail
https://github.com/kubernetes/client-go/blob/97f3d2697cceec0c57cdac5744d7f6ce34c1991d/util/workqueue/default_rate_limiters.go#L50

[shadialtarsha]

Does that make sense?

[harveyxia]

Makes sense, thanks

[harveyxia]

On review, I'm still not sure I understand this change—where is NewZeroDelayManagedRateLimiter being used?

Prior to this upgrade, this repo uses client-go v0.29.3` whose rate limiting logic appears to be identical to the upgraded version, with the exception of the type constraint.

[shadialtarsha]

@harveyxia I opened a PR on our internal ingress controller and pointed to replace github.com/reddit/achilles-sdk => github.com/shadialtarsha/achilles-sdk v0.0.0-20250124125809-a035e576b822

This would be a good way to test it in staging before merging this PR.

Wanna report that the Ingress Controller e2e tests, unit tests and integration tests are all passed successfully