feat: xfn v1beta implementation

[phisco]

Initial move of xfn from the in-tree implementation, only implementing the new v1beta1 interface.

[phisco]

To test it:

kind create cluster

make -j2 build.all

docker tag build-<...>/xfn-oci-<arch> crossplane/xfn-oci:v0.0.0

kind load docker-image crossplane/xfn-oci:v0.0.0

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: xfn
  name: xfn
spec:
  containers:
  - image: crossplane/xfn-oci:v0.0.0
    name: xfn
    ports:
    - containerPort: 1234
    volumeMounts:
    - mountPath: /xfn
      name: xfn-cache
  volumes:
  - name: xfn-cache
    emptyDir:
      sizeLimit: 1Gi
  restartPolicy: Always
EOF

kubectl port-forward xfn 1234:1234

Now, given an image phisco/xfn-output-v1beta1:v0.4, which was built using the following Dockerfile:

FROM alpine:3.18
RUN apk add --no-cache jq
ENTRYPOINT ["/bin/sh", "-c", "jq '.desired.composite.resource.labels |= {\"labelizer.xfn.crossplane.io/processed\": \"true\"} + .'"]

If we run the following command:

grpcurl -plaintext -d @ localhost:1234 apiextensions.fn.proto.v1beta1.FunctionRunnerService.RunFunction <<EOM
{
  "desired": {
    "composite": {
      "resource": {
        "something": "something"
      }
    }
  },
  "input": {
    "spec": {
      "image": "phisco/xfn-output-v1beta1:v0.4"
    }
  }
}
EOM

We get back:

{
  "desired": {
    "composite": {
      "resource": {
          "labels": {
                "labelizer.xfn.crossplane.io/processed": "true"
              },
          "something": "something"
        }
    }
  }
}

Which is indeed the desired output.

[negz]

@phisco If it's not too hard to do, could you "refactor" this PR such that it starts with a plain copy of the code from c/c in one commit, with your changes as an overlay in separate commits? This will make it easier to just review the changes.

[negz]

Why is this being imported as v1beta12?

[phisco]

I guess the IDE picked that name at some point, I will review import aliases once I rebase it on top of #2.

[negz]

Why is this proto2?

[phisco]

same as above

[phisco]

I did a few more changes than the minimum required ones, but I think I still have a branch with both the implementation working with just a switch, so I can definitely try to make it more understandable.