⚠️ Deprecate client.Options.WarningHandler

[dlipovetsky]

As a follow-up to #2887, and the conversation in #2887 (comment), this deprecates client.Options.WarningHandler.

Instead of using client.Options.WarningHandler users define config.WarningHandler. This change

1. Reduces the number of "sources" of warning handler configuration from two to one, and thereby reduces confusion.
2. Allows users to define custom warning handlers, and thereby increases flexibility.

Deprecation and future removal does not change the default behavior, which is to de-duplicate and surface warnings.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dlipovetsky
Once this PR has been reviewed and has the lgtm label, please assign alvaroaleman for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dlipovetsky]

/cc @sbueringer

[sbueringer]

@dlipovetsky Talked to Vince & Alvaro. We would be also fine with directly removing the field. I think that's okay as folks can just easily pass in our implementation via rest.Config

[dlipovetsky]

@dlipovetsky Talked to Vince & Alvaro. We would be also fine with directly removing the field. I think that's okay as folks can just easily pass in our implementation via rest.Config

Thanks! To keep things simple, I'll open a new PR and reference this one. I think that's ok, since this PR hasn't had implementation reviews.