CLOUDP-58090: Create StatefulSet that starts agent image

[chatton]

This PR configures the stateful set to use an agent image specified by the AGENT_IMAGE environment variable.

The stateful set is configured with default resource requirements. Sample StatefulSet configuration

  spec:
    podManagementPolicy: OrderedReady
    replicas: 3
    revisionHistoryLimit: 10
    selector:
      matchLabels:
        dummy: label
    serviceName: ""
    template:
      metadata:
        creationTimestamp: null
        labels:
          dummy: label
      spec:
        containers:
        - command:
          - agent/mongodb-agent
          - -cluster=/var/lib/automation/config/automation-config.json
          image: <agent-image>
          imagePullPolicy: Always
          name: mongodb-agent
          resources:
            limits:
              cpu: "1"
              memory: 500M
            requests:
              cpu: 500m
              memory: 400M

[LouisPlisso]

did you test this with the sample agent image?

[LouisPlisso]

is this worth passing a struct here so that it's easier to understand what value you pass, and maybe address the use-case of passing no value and taking the default?

[LouisPlisso]

or maybe a builder (again) that comes with default values and you can call .setLimitsCpu(xxx) and so on

[chatton]

I'm on a little bit on the fence about this one. When we're not doing much (just 4 values). I like the simplicity of a single factory-style function. It might make sense to introduce a builder when we need to start . configuring non-defaults here.

[LouisPlisso]

as discuss, un-export New for now, and we'll see later if we need a builder

[LouisPlisso]

when are we getting the commit hook for gofmt and goimports?

[chatton]

@rodrigovalin is working on it now I believe!

[rodrigovalin]

I am, doing it right now

[rodrigovalin]

I think there's one important point we have to discuss here: the AGENT_IMAGE is passed as an env variable to the operator... meaning that every MongoDB resource will use the same agent?

I understand that given our current requirements this implementation is enough, but imagine the process of updating this image (for any reason), that would require a reconfiguration of the operator, which will require a restart of all of the Sts it manages.

I actually prefer the image name being hardcoded in the Sts definition, so we know this is a known defect of the implementation, but not a non-evident defect of the design.

[rodrigovalin]

Discard the returning errors of this function, Default should not fail as the values are known

[rodrigovalin]

Possibly add a unit test that checks that Default() return these values so there's not way we introduce errors in the Default impl.

I mention this because I see a few lines up there checking the resulting value of the Default function

[chatton]

good point about removing the error in this case 👍

[rodrigovalin]

My concerns on my previous review were:

1. AGENT_VERSION should not be an operator configuration

We agreed on leaving this for now:

1. Because we won't have a new agent image in a while
2. It will make it easier to "test" custom images if we had to, specially when starting the project.

The strategy will be revisited later.