feat: support k8s 1.22 and upgrade dependencies

[LucasRoesler]

Description

• Mimic the update-codegen.sh implementation from Flagger, this implementation handles modules correctly.

• The controller code-generator is not compatible with modules and vendor, so this removes the vendor folder and all of the go flags that set the vendor mode.

• Update to client-go 0.21.3, which is the latest version with v1beta1 networking support.

• Create v1 and v2 sub-packages for the controller
  The controller package now contains all common code for the controller.

  The v1 package uses the typed client for the extensions/v1beta1 ingress
  and defines the sync handler responsible for creating and updating
  the ingress.

  The v2 package uses the typed client for the networking/v1 ingress and
  defines the the sync handler responseible for creation and updating
  the ingress.

• Add a helper function to discover the cluster capabilities and use
  this to determine which controller to start.

Motivation and Context

• I have raised an issue to propose this change (required)

Resolves #49

How Has This Been Tested?

WIP

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Impact to existing users

None

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s
• I have added tests to cover my changes.
• All new and existing tests passed.

[LucasRoesler]

@alexellis i made the two requested changes

1. the easy one is just renaming the controller subpackages to v1beta1 and v1 to match the networking api group they use
2. re-adding the vendor folder and adding an alternative technique for installing and using code-gen. my approach mimics the approach in https://github.com/bwplotka/bingo by creating a go-submodule that depends on the correct code-gen version. This allows us to use go mod download -modfile=... meaning we can just use the codegen from the module cache and we don't need to invent any new tooling for fetching and managing it, it is just the native go tooling.

[LucasRoesler]

A pre-built image is available at ghcr.io/lucasroesler/ingress-operator:pr-50

[LucasRoesler]

I tested this in kind with k8s 1.19 using these files

# cluster.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
  - containerPort: 31112 # this is the NodePort created by the helm chart
    hostPort: 8080 # this is your port on localhost
    protocol: TCP

# test.yaml
apiVersion: openfaas.com/v1alpha2
kind: FunctionIngress
metadata:
  name: nodeinfo
  namespace: openfaas
spec:
  domain: "nodeinfo.myfaas.club"
  function: "nodeinfo"
  ingressType: "nginx"
  path: "/v1/profiles/(.*)"

and then

$ kind create cluster --config=cluster.yaml
$ arkade install openfaas \
	--basic-auth=false \
	--clusterrole \
	--ingress-operator \
	--set ingressOperator.image=ghcr.io/lucasroesler/ingress-operator:pr-50


$ faas-cli store deploy nodeinfo
$ kubectl apply -f test.yaml
$ kubectl get ing
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
NAME       CLASS    HOSTS                  ADDRESS   PORTS   AGE
nodeinfo   <none>   nodeinfo.myfaas.club             80      5s

I then upgraded kind and used the latest k8s and got the same results, the ingress was created as expected

[alexellis]

LGTM, I like the simple solution of using the .tools folder. Nicely done.