fix(operator): Only deploy an online store when it is declared - #6591

The red `unit-test-python (3.11, macos-14)` leg is an unrelated CI flake, not caused by this change (which is Go-only, scoped to `infra/feast-operator/`):

```
ERROR sdk/python/tests/unit/test_feature_server.py::test_push_and_get
AssertionError: stdout: b''
stderr: b"Command timed out after 120s: [\x27apply\x27]"
2259 passed, 47 skipped, 1 error
```

A `feast apply` subprocess timed out after 120s on the macOS-14 runner. The macOS-3.12 leg and all Ubuntu legs (3.10/3.11/3.12) passed on this same commit, and `operator-test` is green. I do not have permission to re-run the job from the fork — a maintainer re-run of that single leg should clear it.

@nikolauspschuetz instead I think fix should be to allow online server deployment to opt-out.

Thanks @ntkathole — that makes sense for backward compatibility. Omitting onlineStore today implicitly deploys one, so flipping that default (what this PR currently does) is a breaking change on upgrade for anyone relying on the implicit default.

To make it opt-out instead, I'd keep the current default-on behavior and add an explicit disable switch on the online store spec, mirroring the existing DisableInitContainers idiom already in the CRD:

type OnlineStore struct {
    // Disabled skips deploying the online store service.
    // +optional
    Disabled bool `json:"disabled,omitempty"`

    Server      *ServerConfigs          `json:"server,omitempty"`
    Persistence *OnlineStorePersistence `json:"persistence,omitempty"`
    // ...
}

ApplyDefaultsToStatus would skip the onlineStore defaulting/deployment when disabled is true; omitting the block keeps deploying it exactly as before. The standalone-registry / federated pattern from #6586 would then be expressed explicitly as spec.services.onlineStore.disabled: true.

One clarification so I build the right thing: do you want the opt-out at the whole online-store level (skip both persistence and the serving pod), or only the online server (serving pod), keeping the online store config? Happy to rework the PR either way once you confirm.

opt-out at the whole online-store level (skip both persistence and the serving pod), or only the online server (serving pod), keeping the online store config?

opt-out at the whole onlineStore level (disabled: true), not server-only.

Thanks — reworked it to opt-out. The default is back to deploying the online store, so nothing changes on upgrade for existing setups. Setting spec.services.onlineStore.disabled: true now skips it entirely (serving pod and persistence), which covers the registry-only / offline-only case from #6586. It's gated through isOnlineStore(), so metrics and the service monitor drop off with it too.

@nikolauspschuetz Please resolve conflicts

Rebased onto master and resolved the conflict, @ntkathole. The only conflict was in .secrets.baseline (a shifted line_number and the generated_at timestamp — my disabled field pushed the tracked line in featurestore_types.go from 937 to 941); the operator code merged cleanly.

Ran the operator suite locally against the envtest harness (k8s 1.31.0) after the rebase — internal/controller/services passes, including the isOnlineStore / disabled: true cases in util_test.go. Ready for another look.

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.35%. Comparing base (0f149a9) to head (a5466a5).
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@           Coverage Diff           @@
##           master    #6591   +/-   ##
=======================================
  Coverage   46.35%   46.35%           
=======================================
  Files         414      414           
  Lines       50052    50052           
  Branches     7151     7151           
=======================================
  Hits        23201    23201           
  Misses      25229    25229           
  Partials     1622     1622           

@nikolauspschuetz need to fix linting