remove unneeded k8s code

There is a lot of unneeded code, k8s is the by far the biggest
dependency in podman. We should remove as much as possible so that we
only have the stuff left that we use.

This is just a quick skim over the code which removes a lot of the
generated code and many packages that are now unused.
I know that this will be impossible to properly review. I will try to
make smaller changes in follow up work.

Right now this reduces about 8 MB in binary size!!!

[NO NEW TESTS NEEDED] Hopefully existing tests will catch any problems.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>

8 files changed, 0 insertions, 1089 deletions

diff --git a/vendor/github.com/go-logr/logr/.golangci.yaml b/vendor/github.com/go-logr/logr/.golangci.yaml
deleted file mode 100644
index 94ff801df..000000000
--- a/vendor/github.com/go-logr/logr/.golangci.yaml
+++ /dev/null
@@ -1,29 +0,0 @@
-run:
-  timeout: 1m
-  tests: true
-
-linters:
-  disable-all: true
-  enable:
-    - asciicheck
-    - deadcode
-    - errcheck
-    - forcetypeassert
-    - gocritic
-    - gofmt
-    - goimports
-    - gosimple
-    - govet
-    - ineffassign
-    - misspell
-    - revive
-    - staticcheck
-    - structcheck
-    - typecheck
-    - unused
-    - varcheck
-
-issues:
-  exclude-use-default: false
-  max-issues-per-linter: 0
-  max-same-issues: 10
diff --git a/vendor/github.com/go-logr/logr/CHANGELOG.md b/vendor/github.com/go-logr/logr/CHANGELOG.md
deleted file mode 100644
index c35696004..000000000
--- a/vendor/github.com/go-logr/logr/CHANGELOG.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# CHANGELOG
-
-## v1.0.0-rc1
-
-This is the first logged release.  Major changes (including breaking changes)
-have occurred since earlier tags.
diff --git a/vendor/github.com/go-logr/logr/CONTRIBUTING.md b/vendor/github.com/go-logr/logr/CONTRIBUTING.md
deleted file mode 100644
index 5d37e294c..000000000
--- a/vendor/github.com/go-logr/logr/CONTRIBUTING.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Contributing
-
-Logr is open to pull-requests, provided they fit within the intended scope of
-the project.  Specifically, this library aims to be VERY small and minimalist,
-with no external dependencies.
-
-## Compatibility
-
-This project intends to follow [semantic versioning](http://semver.org) and
-is very strict about compatibility.  Any proposed changes MUST follow those
-rules.
-
-## Performance
-
-As a logging library, logr must be as light-weight as possible.  Any proposed
-code change must include results of running the [benchmark](./benchmark)
-before and after the change.
diff --git a/vendor/github.com/go-logr/logr/LICENSE b/vendor/github.com/go-logr/logr/LICENSE
deleted file mode 100644
index 8dada3eda..000000000
--- a/vendor/github.com/go-logr/logr/LICENSE
+++ /dev/null
@@ -1,201 +0,0 @@
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
-
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
-
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
-
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
-
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
-
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
-
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
-
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
-
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
-
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
-
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
-
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
-
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
-
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
-
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
-
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
-
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
-
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
-
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
-
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
-
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
-
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
-
-   END OF TERMS AND CONDITIONS
-
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "{}"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright {yyyy} {name of copyright owner}
-
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
-
-       http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.
diff --git a/vendor/github.com/go-logr/logr/README.md b/vendor/github.com/go-logr/logr/README.md
deleted file mode 100644
index ad825f5f0..000000000
--- a/vendor/github.com/go-logr/logr/README.md
+++ /dev/null
@@ -1,278 +0,0 @@
-# A minimal logging API for Go
-
-[![Go Reference](https://pkg.go.dev/badge/github.com/go-logr/logr.svg)](https://pkg.go.dev/github.com/go-logr/logr)
-
-logr offers an(other) opinion on how Go programs and libraries can do logging
-without becoming coupled to a particular logging implementation.  This is not
-an implementation of logging - it is an API.  In fact it is two APIs with two
-different sets of users.
-
-The `Logger` type is intended for application and library authors.  It provides
-a relatively small API which can be used everywhere you want to emit logs.  It
-defers the actual act of writing logs (to files, to stdout, or whatever) to the
-`LogSink` interface.
-
-The `LogSink` interface is intended for logging library implementers.  It is a
-pure interface which can be implemented by logging frameworks to provide the actual logging
-functionality.
-
-This decoupling allows application and library developers to write code in
-terms of `logr.Logger` (which has very low dependency fan-out) while the
-implementation of logging is managed "up stack" (e.g. in or near `main()`.)
-Application developers can then switch out implementations as necessary.
-
-Many people assert that libraries should not be logging, and as such efforts
-like this are pointless.  Those people are welcome to convince the authors of
-the tens-of-thousands of libraries that *DO* write logs that they are all
-wrong.  In the meantime, logr takes a more practical approach.
-
-## Typical usage
-
-Somewhere, early in an application's life, it will make a decision about which
-logging library (implementation) it actually wants to use.  Something like:
-
-```
-    func main() {
-        // ... other setup code ...
-
-        // Create the "root" logger.  We have chosen the "logimpl" implementation,
-        // which takes some initial parameters and returns a logr.Logger.
-        logger := logimpl.New(param1, param2)
-
-        // ... other setup code ...
-```
-
-Most apps will call into other libraries, create structures to govern the flow,
-etc.  The `logr.Logger` object can be passed to these other libraries, stored
-in structs, or even used as a package-global variable, if needed.  For example:
-
-```
-    app := createTheAppObject(logger)
-    app.Run()
-```
-
-Outside of this early setup, no other packages need to know about the choice of
-implementation.  They write logs in terms of the `logr.Logger` that they
-received:
-
-```
-    type appObject struct {
-        // ... other fields ...
-        logger logr.Logger
-        // ... other fields ...
-    }
-
-    func (app *appObject) Run() {
-        app.logger.Info("starting up", "timestamp", time.Now())
-
-        // ... app code ...
-```
-
-## Background
-
-If the Go standard library had defined an interface for logging, this project
-probably would not be needed.  Alas, here we are.
-
-### Inspiration
-
-Before you consider this package, please read [this blog post by the
-inimitable Dave Cheney][warning-makes-no-sense].  We really appreciate what
-he has to say, and it largely aligns with our own experiences.
-
-### Differences from Dave's ideas
-
-The main differences are:
-
-1. Dave basically proposes doing away with the notion of a logging API in favor
-of `fmt.Printf()`.  We disagree, especially when you consider things like output
-locations, timestamps, file and line decorations, and structured logging.  This
-package restricts the logging API to just 2 types of logs: info and error.
-
-Info logs are things you want to tell the user which are not errors.  Error
-logs are, well, errors.  If your code receives an `error` from a subordinate
-function call and is logging that `error` *and not returning it*, use error
-logs.
-
-2. Verbosity-levels on info logs.  This gives developers a chance to indicate
-arbitrary grades of importance for info logs, without assigning names with
-semantic meaning such as "warning", "trace", and "debug."  Superficially this
-may feel very similar, but the primary difference is the lack of semantics.
-Because verbosity is a numerical value, it's safe to assume that an app running
-with higher verbosity means more (and less important) logs will be generated.
-
-## Implementations (non-exhaustive)
-
-There are implementations for the following logging libraries:
-
-- **a function** (can bridge to non-structured libraries): [funcr](https://github.com/go-logr/logr/tree/master/funcr)
-- **github.com/google/glog**: [glogr](https://github.com/go-logr/glogr)
-- **k8s.io/klog** (for Kubernetes): [klogr](https://git.k8s.io/klog/klogr)
-- **go.uber.org/zap**: [zapr](https://github.com/go-logr/zapr)
-- **log** (the Go standard library logger): [stdr](https://github.com/go-logr/stdr)
-- **github.com/sirupsen/logrus**: [logrusr](https://github.com/bombsimon/logrusr)
-- **github.com/wojas/genericr**: [genericr](https://github.com/wojas/genericr) (makes it easy to implement your own backend)
-- **logfmt** (Heroku style [logging](https://www.brandur.org/logfmt)): [logfmtr](https://github.com/iand/logfmtr)
-- **github.com/rs/zerolog**: [zerologr](https://github.com/go-logr/zerologr)
-
-## FAQ
-
-### Conceptual
-
-#### Why structured logging?
-
-- **Structured logs are more easily queryable**: Since you've got
-  key-value pairs, it's much easier to query your structured logs for
-  particular values by filtering on the contents of a particular key --
-  think searching request logs for error codes, Kubernetes reconcilers for
-  the name and namespace of the reconciled object, etc.
-
-- **Structured logging makes it easier to have cross-referenceable logs**:
-  Similarly to searchability, if you maintain conventions around your
-  keys, it becomes easy to gather all log lines related to a particular
-  concept.
-
-- **Structured logs allow better dimensions of filtering**: if you have
-  structure to your logs, you've got more precise control over how much
-  information is logged -- you might choose in a particular configuration
-  to log certain keys but not others, only log lines where a certain key
-  matches a certain value, etc., instead of just having v-levels and names
-  to key off of.
-
-- **Structured logs better represent structured data**: sometimes, the
-  data that you want to log is inherently structured (think tuple-link
-  objects.)  Structured logs allow you to preserve that structure when
-  outputting.
-
-#### Why V-levels?
-
-**V-levels give operators an easy way to control the chattiness of log
-operations**.  V-levels provide a way for a given package to distinguish
-the relative importance or verbosity of a given log message.  Then, if
-a particular logger or package is logging too many messages, the user
-of the package can simply change the v-levels for that library.
-
-#### Why not named levels, like Info/Warning/Error?
-
-Read [Dave Cheney's post][warning-makes-no-sense].  Then read [Differences
-from Dave's ideas](#differences-from-daves-ideas).
-
-#### Why not allow format strings, too?
-
-**Format strings negate many of the benefits of structured logs**:
-
-- They're not easily searchable without resorting to fuzzy searching,
-  regular expressions, etc.
-
-- They don't store structured data well, since contents are flattened into
-  a string.
-
-- They're not cross-referenceable.
-
-- They don't compress easily, since the message is not constant.
-
-(Unless you turn positional parameters into key-value pairs with numerical
-keys, at which point you've gotten key-value logging with meaningless
-keys.)
-
-### Practical
-
-#### Why key-value pairs, and not a map?
-
-Key-value pairs are *much* easier to optimize, especially around
-allocations.  Zap (a structured logger that inspired logr's interface) has
-[performance measurements](https://github.com/uber-go/zap#performance)
-that show this quite nicely.
-
-While the interface ends up being a little less obvious, you get
-potentially better performance, plus avoid making users type
-`map[string]string{}` every time they want to log.
-
-#### What if my V-levels differ between libraries?
-
-That's fine.  Control your V-levels on a per-logger basis, and use the
-`WithName` method to pass different loggers to different libraries.
-
-Generally, you should take care to ensure that you have relatively
-consistent V-levels within a given logger, however, as this makes deciding
-on what verbosity of logs to request easier.
-
-#### But I really want to use a format string!
-
-That's not actually a question.  Assuming your question is "how do
-I convert my mental model of logging with format strings to logging with
-constant messages":
-
-1. Figure out what the error actually is, as you'd write in a TL;DR style,
-   and use that as a message.
-
-2. For every place you'd write a format specifier, look to the word before
-   it, and add that as a key value pair.
-
-For instance, consider the following examples (all taken from spots in the
-Kubernetes codebase):
-
-- `klog.V(4).Infof("Client is returning errors: code %v, error %v",
-  responseCode, err)` becomes `logger.Error(err, "client returned an
-  error", "code", responseCode)`
-
-- `klog.V(4).Infof("Got a Retry-After %ds response for attempt %d to %v",
-  seconds, retries, url)` becomes `logger.V(4).Info("got a retry-after
-  response when requesting url", "attempt", retries, "after
-  seconds", seconds, "url", url)`
-
-If you *really* must use a format string, use it in a key's value, and
-call `fmt.Sprintf` yourself.  For instance: `log.Printf("unable to
-reflect over type %T")` becomes `logger.Info("unable to reflect over
-type", "type", fmt.Sprintf("%T"))`.  In general though, the cases where
-this is necessary should be few and far between.
-
-#### How do I choose my V-levels?
-
-This is basically the only hard constraint: increase V-levels to denote
-more verbose or more debug-y logs.
-
-Otherwise, you can start out with `0` as "you always want to see this",
-`1` as "common logging that you might *possibly* want to turn off", and
-`10` as "I would like to performance-test your log collection stack."
-
-Then gradually choose levels in between as you need them, working your way
-down from 10 (for debug and trace style logs) and up from 1 (for chattier
-info-type logs.)
-
-#### How do I choose my keys?
-
-Keys are fairly flexible, and can hold more or less any string
-value. For best compatibility with implementations and consistency
-with existing code in other projects, there are a few conventions you
-should consider.
-
-- Make your keys human-readable.
-- Constant keys are generally a good idea.
-- Be consistent across your codebase.
-- Keys should naturally match parts of the message string.
-- Use lower case for simple keys and
-  [lowerCamelCase](https://en.wiktionary.org/wiki/lowerCamelCase) for
-  more complex ones. Kubernetes is one example of a project that has
-  [adopted that
-  convention](https://github.com/kubernetes/community/blob/HEAD/contributors/devel/sig-instrumentation/migration-to-structured-logging.md#name-arguments).
-
-While key names are mostly unrestricted (and spaces are acceptable),
-it's generally a good idea to stick to printable ascii characters, or at
-least match the general character set of your log lines.
-
-#### Why should keys be constant values?
-
-The point of structured logging is to make later log processing easier.  Your
-keys are, effectively, the schema of each log message.  If you use different
-keys across instances of the same log line, you will make your structured logs
-much harder to use.  `Sprintf()` is for values, not for keys!
-
-#### Why is this not a pure interface?
-
-The Logger type is implemented as a struct in order to allow the Go compiler to
-optimize things like high-V `Info` logs that are not triggered.  Not all of
-these implementations are implemented yet, but this structure was suggested as
-a way to ensure they *can* be implemented.  All of the real work is behind the
-`LogSink` interface.
-
-[warning-makes-no-sense]: http://dave.cheney.net/2015/11/05/lets-talk-about-logging
diff --git a/vendor/github.com/go-logr/logr/discard.go b/vendor/github.com/go-logr/logr/discard.go
deleted file mode 100644
index 9d92a38f1..000000000
--- a/vendor/github.com/go-logr/logr/discard.go
+++ /dev/null
@@ -1,54 +0,0 @@
-/*
-Copyright 2020 The logr Authors.
-
-Licensed under the Apache License, Version 2.0 (the "License");
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-*/
-
-package logr
-
-// Discard returns a Logger that discards all messages logged to it.  It can be
-// used whenever the caller is not interested in the logs.  Logger instances
-// produced by this function always compare as equal.
-func Discard() Logger {
-	return Logger{
-		level: 0,
-		sink:  discardLogSink{},
-	}
-}
-
-// discardLogSink is a LogSink that discards all messages.
-type discardLogSink struct{}
-
-// Verify that it actually implements the interface
-var _ LogSink = discardLogSink{}
-
-func (l discardLogSink) Init(RuntimeInfo) {
-}
-
-func (l discardLogSink) Enabled(int) bool {
-	return false
-}
-
-func (l discardLogSink) Info(int, string, ...interface{}) {
-}
-
-func (l discardLogSink) Error(error, string, ...interface{}) {
-}
-
-func (l discardLogSink) WithValues(...interface{}) LogSink {
-	return l
-}
-
-func (l discardLogSink) WithName(string) LogSink {
-	return l
-}
diff --git a/vendor/github.com/go-logr/logr/go.mod b/vendor/github.com/go-logr/logr/go.mod
deleted file mode 100644
index 7baec9b57..000000000
--- a/vendor/github.com/go-logr/logr/go.mod
+++ /dev/null
@@ -1,3 +0,0 @@
-module github.com/go-logr/logr
-
-go 1.16
diff --git a/vendor/github.com/go-logr/logr/logr.go b/vendor/github.com/go-logr/logr/logr.go
deleted file mode 100644
index c05482a20..000000000
--- a/vendor/github.com/go-logr/logr/logr.go
+++ /dev/null
@@ -1,501 +0,0 @@
-/*
-Copyright 2019 The logr Authors.
-
-Licensed under the Apache License, Version 2.0 (the "License");
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-*/
-
-// This design derives from Dave Cheney's blog:
-//     http://dave.cheney.net/2015/11/05/lets-talk-about-logging
-
-// Package logr defines a general-purpose logging API and abstract interfaces
-// to back that API.  Packages in the Go ecosystem can depend on this package,
-// while callers can implement logging with whatever backend is appropriate.
-//
-// Usage
-//
-// Logging is done using a Logger instance.  Logger is a concrete type with
-// methods, which defers the actual logging to a LogSink interface.  The main
-// methods of Logger are Info() and Error().  Arguments to Info() and Error()
-// are key/value pairs rather than printf-style formatted strings, emphasizing
-// "structured logging".
-//
-// With Go's standard log package, we might write:
-//   log.Printf("setting target value %s", targetValue)
-//
-// With logr's structured logging, we'd write:
-//   logger.Info("setting target", "value", targetValue)
-//
-// Errors are much the same.  Instead of:
-//   log.Printf("failed to open the pod bay door for user %s: %v", user, err)
-//
-// We'd write:
-//   logger.Error(err, "failed to open the pod bay door", "user", user)
-//
-// Info() and Error() are very similar, but they are separate methods so that
-// LogSink implementations can choose to do things like attach additional
-// information (such as stack traces) on calls to Error(). Error() messages are
-// always logged, regardless of the current verbosity.  If there is no error
-// instance available, passing nil is valid.
-//
-// Verbosity
-//
-// Often we want to log information only when the application in "verbose
-// mode".  To write log lines that are more verbose, Logger has a V() method.
-// The higher the V-level of a log line, the less critical it is considered.
-// Log-lines with V-levels that are not enabled (as per the LogSink) will not
-// be written.  Level V(0) is the default, and logger.V(0).Info() has the same
-// meaning as logger.Info().  Negative V-levels have the same meaning as V(0).
-// Error messages do not have a verbosity level and are always logged.
-//
-// Where we might have written:
-//   if flVerbose >= 2 {
-//       log.Printf("an unusual thing happened")
-//   }
-//
-// We can write:
-//   logger.V(2).Info("an unusual thing happened")
-//
-// Logger Names
-//
-// Logger instances can have name strings so that all messages logged through
-// that instance have additional context.  For example, you might want to add
-// a subsystem name:
-//
-//   logger.WithName("compactor").Info("started", "time", time.Now())
-//
-// The WithName() method returns a new Logger, which can be passed to
-// constructors or other functions for further use.  Repeated use of WithName()
-// will accumulate name "segments".  These name segments will be joined in some
-// way by the LogSink implementation.  It is strongly recommended that name
-// segments contain simple identifiers (letters, digits, and hyphen), and do
-// not contain characters that could muddle the log output or confuse the
-// joining operation (e.g. whitespace, commas, periods, slashes, brackets,
-// quotes, etc).
-//
-// Saved Values
-//
-// Logger instances can store any number of key/value pairs, which will be
-// logged alongside all messages logged through that instance.  For example,
-// you might want to create a Logger instance per managed object:
-//
-// With the standard log package, we might write:
-//   log.Printf("decided to set field foo to value %q for object %s/%s",
-//       targetValue, object.Namespace, object.Name)
-//
-// With logr we'd write:
-//   // Elsewhere: set up the logger to log the object name.
-//   obj.logger = mainLogger.WithValues(
-//       "name", obj.name, "namespace", obj.namespace)
-//
-//   // later on...
-//   obj.logger.Info("setting foo", "value", targetValue)
-//
-// Best Practices
-//
-// Logger has very few hard rules, with the goal that LogSink implementations
-// might have a lot of freedom to differentiate.  There are, however, some
-// things to consider.
-//
-// The log message consists of a constant message attached to the log line.
-// This should generally be a simple description of what's occurring, and should
-// never be a format string.  Variable information can then be attached using
-// named values.
-//
-// Keys are arbitrary strings, but should generally be constant values.  Values
-// may be any Go value, but how the value is formatted is determined by the
-// LogSink implementation.
-//
-// Key Naming Conventions
-//
-// Keys are not strictly required to conform to any specification or regex, but
-// it is recommended that they:
-//   * be human-readable and meaningful (not auto-generated or simple ordinals)
-//   * be constant (not dependent on input data)
-//   * contain only printable characters
-//   * not contain whitespace or punctuation
-//   * use lower case for simple keys and lowerCamelCase for more complex ones
-//
-// These guidelines help ensure that log data is processed properly regardless
-// of the log implementation.  For example, log implementations will try to
-// output JSON data or will store data for later database (e.g. SQL) queries.
-//
-// While users are generally free to use key names of their choice, it's
-// generally best to avoid using the following keys, as they're frequently used
-// by implementations:
-//   * "caller": the calling information (file/line) of a particular log line
-//   * "error": the underlying error value in the `Error` method
-//   * "level": the log level
-//   * "logger": the name of the associated logger
-//   * "msg": the log message
-//   * "stacktrace": the stack trace associated with a particular log line or
-//                   error (often from the `Error` message)
-//   * "ts": the timestamp for a log line
-//
-// Implementations are encouraged to make use of these keys to represent the
-// above concepts, when necessary (for example, in a pure-JSON output form, it
-// would be necessary to represent at least message and timestamp as ordinary
-// named values).
-//
-// Break Glass
-//
-// Implementations may choose to give callers access to the underlying
-// logging implementation.  The recommended pattern for this is:
-//   // Underlier exposes access to the underlying logging implementation.
-//   // Since callers only have a logr.Logger, they have to know which
-//   // implementation is in use, so this interface is less of an abstraction
-//   // and more of way to test type conversion.
-//   type Underlier interface {
-//       GetUnderlying() <underlying-type>
-//   }
-//
-// Logger grants access to the sink to enable type assertions like this:
-//   func DoSomethingWithImpl(log logr.Logger) {
-//       if underlier, ok := log.GetSink()(impl.Underlier) {
-//          implLogger := underlier.GetUnderlying()
-//          ...
-//       }
-//   }
-//
-// Custom `With*` functions can be implemented by copying the complete
-// Logger struct and replacing the sink in the copy:
-//   // WithFooBar changes the foobar parameter in the log sink and returns a
-//   // new logger with that modified sink.  It does nothing for loggers where
-//   // the sink doesn't support that parameter.
-//   func WithFoobar(log logr.Logger, foobar int) logr.Logger {
-//      if foobarLogSink, ok := log.GetSink()(FoobarSink); ok {
-//         log = log.WithSink(foobarLogSink.WithFooBar(foobar))
-//      }
-//      return log
-//   }
-//
-// Don't use New to construct a new Logger with a LogSink retrieved from an
-// existing Logger. Source code attribution might not work correctly and
-// unexported fields in Logger get lost.
-//
-// Beware that the same LogSink instance may be shared by different logger
-// instances. Calling functions that modify the LogSink will affect all of
-// those.
-package logr
-
-import (
-	"context"
-)
-
-// New returns a new Logger instance.  This is primarily used by libraries
-// implementing LogSink, rather than end users.
-func New(sink LogSink) Logger {
-	logger := Logger{}
-	logger.setSink(sink)
-	sink.Init(runtimeInfo)
-	return logger
-}
-
-// setSink stores the sink and updates any related fields. It mutates the
-// logger and thus is only safe to use for loggers that are not currently being
-// used concurrently.
-func (l *Logger) setSink(sink LogSink) {
-	l.sink = sink
-}
-
-// GetSink returns the stored sink.
-func (l Logger) GetSink() LogSink {
-	return l.sink
-}
-
-// WithSink returns a copy of the logger with the new sink.
-func (l Logger) WithSink(sink LogSink) Logger {
-	l.setSink(sink)
-	return l
-}
-
-// Logger is an interface to an abstract logging implementation.  This is a
-// concrete type for performance reasons, but all the real work is passed on to
-// a LogSink.  Implementations of LogSink should provide their own constructors
-// that return Logger, not LogSink.
-//
-// The underlying sink can be accessed through GetSink and be modified through
-// WithSink. This enables the implementation of custom extensions (see "Break
-// Glass" in the package documentation). Normally the sink should be used only
-// indirectly.
-type Logger struct {
-	sink  LogSink
-	level int
-}
-
-// Enabled tests whether this Logger is enabled.  For example, commandline
-// flags might be used to set the logging verbosity and disable some info logs.
-func (l Logger) Enabled() bool {
-	return l.sink.Enabled(l.level)
-}
-
-// Info logs a non-error message with the given key/value pairs as context.
-//
-// The msg argument should be used to add some constant description to the log
-// line.  The key/value pairs can then be used to add additional variable
-// information.  The key/value pairs must alternate string keys and arbitrary
-// values.
-func (l Logger) Info(msg string, keysAndValues ...interface{}) {
-	if l.Enabled() {
-		if withHelper, ok := l.sink.(CallStackHelperLogSink); ok {
-			withHelper.GetCallStackHelper()()
-		}
-		l.sink.Info(l.level, msg, keysAndValues...)
-	}
-}
-
-// Error logs an error, with the given message and key/value pairs as context.
-// It functions similarly to Info, but may have unique behavior, and should be
-// preferred for logging errors (see the package documentations for more
-// information). The log message will always be emitted, regardless of
-// verbosity level.
-//
-// The msg argument should be used to add context to any underlying error,
-// while the err argument should be used to attach the actual error that
-// triggered this log line, if present. The err parameter is optional
-// and nil may be passed instead of an error instance.
-func (l Logger) Error(err error, msg string, keysAndValues ...interface{}) {
-	if withHelper, ok := l.sink.(CallStackHelperLogSink); ok {
-		withHelper.GetCallStackHelper()()
-	}
-	l.sink.Error(err, msg, keysAndValues...)
-}
-
-// V returns a new Logger instance for a specific verbosity level, relative to
-// this Logger.  In other words, V-levels are additive.  A higher verbosity
-// level means a log message is less important.  Negative V-levels are treated
-// as 0.
-func (l Logger) V(level int) Logger {
-	if level < 0 {
-		level = 0
-	}
-	l.level += level
-	return l
-}
-
-// WithValues returns a new Logger instance with additional key/value pairs.
-// See Info for documentation on how key/value pairs work.
-func (l Logger) WithValues(keysAndValues ...interface{}) Logger {
-	l.setSink(l.sink.WithValues(keysAndValues...))
-	return l
-}
-
-// WithName returns a new Logger instance with the specified name element added
-// to the Logger's name.  Successive calls with WithName append additional
-// suffixes to the Logger's name.  It's strongly recommended that name segments
-// contain only letters, digits, and hyphens (see the package documentation for
-// more information).
-func (l Logger) WithName(name string) Logger {
-	l.setSink(l.sink.WithName(name))
-	return l
-}
-
-// WithCallDepth returns a Logger instance that offsets the call stack by the
-// specified number of frames when logging call site information, if possible.
-// This is useful for users who have helper functions between the "real" call
-// site and the actual calls to Logger methods.  If depth is 0 the attribution
-// should be to the direct caller of this function.  If depth is 1 the
-// attribution should skip 1 call frame, and so on.  Successive calls to this
-// are additive.
-//
-// If the underlying log implementation supports a WithCallDepth(int) method,
-// it will be called and the result returned.  If the implementation does not
-// support CallDepthLogSink, the original Logger will be returned.
-//
-// To skip one level, WithCallStackHelper() should be used instead of
-// WithCallDepth(1) because it works with implementions that support the
-// CallDepthLogSink and/or CallStackHelperLogSink interfaces.
-func (l Logger) WithCallDepth(depth int) Logger {
-	if withCallDepth, ok := l.sink.(CallDepthLogSink); ok {
-		l.setSink(withCallDepth.WithCallDepth(depth))
-	}
-	return l
-}
-
-// WithCallStackHelper returns a new Logger instance that skips the direct
-// caller when logging call site information, if possible.  This is useful for
-// users who have helper functions between the "real" call site and the actual
-// calls to Logger methods and want to support loggers which depend on marking
-// each individual helper function, like loggers based on testing.T.
-//
-// In addition to using that new logger instance, callers also must call the
-// returned function.
-//
-// If the underlying log implementation supports a WithCallDepth(int) method,
-// WithCallDepth(1) will be called to produce a new logger. If it supports a
-// WithCallStackHelper() method, that will be also called. If the
-// implementation does not support either of these, the original Logger will be
-// returned.
-func (l Logger) WithCallStackHelper() (func(), Logger) {
-	var helper func()
-	if withCallDepth, ok := l.sink.(CallDepthLogSink); ok {
-		l.setSink(withCallDepth.WithCallDepth(1))
-	}
-	if withHelper, ok := l.sink.(CallStackHelperLogSink); ok {
-		helper = withHelper.GetCallStackHelper()
-	} else {
-		helper = func() {}
-	}
-	return helper, l
-}
-
-// contextKey is how we find Loggers in a context.Context.
-type contextKey struct{}
-
-// FromContext returns a Logger from ctx or an error if no Logger is found.
-func FromContext(ctx context.Context) (Logger, error) {
-	if v, ok := ctx.Value(contextKey{}).(Logger); ok {
-		return v, nil
-	}
-
-	return Logger{}, notFoundError{}
-}
-
-// notFoundError exists to carry an IsNotFound method.
-type notFoundError struct{}
-
-func (notFoundError) Error() string {
-	return "no logr.Logger was present"
-}
-
-func (notFoundError) IsNotFound() bool {
-	return true
-}
-
-// FromContextOrDiscard returns a Logger from ctx.  If no Logger is found, this
-// returns a Logger that discards all log messages.
-func FromContextOrDiscard(ctx context.Context) Logger {
-	if v, ok := ctx.Value(contextKey{}).(Logger); ok {
-		return v
-	}
-
-	return Discard()
-}
-
-// NewContext returns a new Context, derived from ctx, which carries the
-// provided Logger.
-func NewContext(ctx context.Context, logger Logger) context.Context {
-	return context.WithValue(ctx, contextKey{}, logger)
-}
-
-// RuntimeInfo holds information that the logr "core" library knows which
-// LogSinks might want to know.
-type RuntimeInfo struct {
-	// CallDepth is the number of call frames the logr library adds between the
-	// end-user and the LogSink.  LogSink implementations which choose to print
-	// the original logging site (e.g. file & line) should climb this many
-	// additional frames to find it.
-	CallDepth int
-}
-
-// runtimeInfo is a static global.  It must not be changed at run time.
-var runtimeInfo = RuntimeInfo{
-	CallDepth: 1,
-}
-
-// LogSink represents a logging implementation.  End-users will generally not
-// interact with this type.
-type LogSink interface {
-	// Init receives optional information about the logr library for LogSink
-	// implementations that need it.
-	Init(info RuntimeInfo)
-
-	// Enabled tests whether this LogSink is enabled at the specified V-level.
-	// For example, commandline flags might be used to set the logging
-	// verbosity and disable some info logs.
-	Enabled(level int) bool
-
-	// Info logs a non-error message with the given key/value pairs as context.
-	// The level argument is provided for optional logging.  This method will
-	// only be called when Enabled(level) is true. See Logger.Info for more
-	// details.
-	Info(level int, msg string, keysAndValues ...interface{})
-
-	// Error logs an error, with the given message and key/value pairs as
-	// context.  See Logger.Error for more details.
-	Error(err error, msg string, keysAndValues ...interface{})
-
-	// WithValues returns a new LogSink with additional key/value pairs.  See
-	// Logger.WithValues for more details.
-	WithValues(keysAndValues ...interface{}) LogSink
-
-	// WithName returns a new LogSink with the specified name appended.  See
-	// Logger.WithName for more details.
-	WithName(name string) LogSink
-}
-
-// CallDepthLogSink represents a Logger that knows how to climb the call stack
-// to identify the original call site and can offset the depth by a specified
-// number of frames.  This is useful for users who have helper functions
-// between the "real" call site and the actual calls to Logger methods.
-// Implementations that log information about the call site (such as file,
-// function, or line) would otherwise log information about the intermediate
-// helper functions.
-//
-// This is an optional interface and implementations are not required to
-// support it.
-type CallDepthLogSink interface {
-	// WithCallDepth returns a LogSink that will offset the call
-	// stack by the specified number of frames when logging call
-	// site information.
-	//
-	// If depth is 0, the LogSink should skip exactly the number
-	// of call frames defined in RuntimeInfo.CallDepth when Info
-	// or Error are called, i.e. the attribution should be to the
-	// direct caller of Logger.Info or Logger.Error.
-	//
-	// If depth is 1 the attribution should skip 1 call frame, and so on.
-	// Successive calls to this are additive.
-	WithCallDepth(depth int) LogSink
-}
-
-// CallStackHelperLogSink represents a Logger that knows how to climb
-// the call stack to identify the original call site and can skip
-// intermediate helper functions if they mark themselves as
-// helper. Go's testing package uses that approach.
-//
-// This is useful for users who have helper functions between the
-// "real" call site and the actual calls to Logger methods.
-// Implementations that log information about the call site (such as
-// file, function, or line) would otherwise log information about the
-// intermediate helper functions.
-//
-// This is an optional interface and implementations are not required
-// to support it. Implementations that choose to support this must not
-// simply implement it as WithCallDepth(1), because
-// Logger.WithCallStackHelper will call both methods if they are
-// present. This should only be implemented for LogSinks that actually
-// need it, as with testing.T.
-type CallStackHelperLogSink interface {
-	// GetCallStackHelper returns a function that must be called
-	// to mark the direct caller as helper function when logging
-	// call site information.
-	GetCallStackHelper() func()
-}
-
-// Marshaler is an optional interface that logged values may choose to
-// implement. Loggers with structured output, such as JSON, should
-// log the object return by the MarshalLog method instead of the
-// original value.
-type Marshaler interface {
-	// MarshalLog can be used to:
-	//   - ensure that structs are not logged as strings when the original
-	//     value has a String method: return a different type without a
-	//     String method
-	//   - select which fields of a complex type should get logged:
-	//     return a simpler struct with fewer fields
-	//   - log unexported fields: return a different struct
-	//     with exported fields
-	//
-	// It may return any value of any type.
-	MarshalLog() interface{}
-}