[realnedsanders]

Dolt's sql-server can serve its databases over its user-facing remotes
API, the top-level remotesapi section of its configuration. Clients then
clone, fetch and push with dolt clone http://<host>:<port>/<database>.
The operator renders only cluster.remotesapi, and only with replication
enabled. It also patches its ConfigMap back on every reconcile. So today an
operator-managed DoltDB cannot serve the user-facing API, even by hand.

The operator also cannot set behavior.event_scheduler, so stored events
always run (Dolt's default is ON). An application that admits only plain
data has no way to turn the scheduler off declaratively.

This PR adds two optional fields to the DoltDB spec. Nothing changes for a
DoltDB that sets neither.

• spec.server.remotesAPI renders remotesapi.port and
  remotesapi.read_only.
  • The port defaults to 50052, apart from the replication port 50051, so
    the two can be used together.
  • The port is added as http-remotesapi to the container and to the
    primary, reader and internal Services. One port carries both the gRPC
    calls and the plain HTTP table-file transfers.
• spec.server.behavior.eventScheduler (ON or OFF) renders
  behavior.event_scheduler. Empty keeps Dolt's default.

apiVersion: k8s.dolthub.com/v1alpha
kind: DoltDB
spec:
  server:
    behavior:
      eventScheduler: "OFF"
    remotesAPI:
      port: 50052

renders

behavior:
  auto_gc_behavior:
    enable: false
  event_scheduler: "OFF"
remotesapi:
  port: 50052

Security note for users

An unauthenticated request to Dolt's remotes API runs as root with an
empty password (remotesrv/http.go). The remotes port therefore needs
network policy that admits only trusted clients. This PR does not change
that behaviour; it only lets the operator render the API that Dolt already
has. The field's documentation could say so, if you prefer.

Testing

• make generate manifests: the deepcopy and the three generated CRDs gain
  only the new fields.
• Unit tests:
  • config rendering, with and without the fields (pkg/dolt);
  • container and Service ports (pkg/builder);
  • go test $(go list ./... | grep -v /internal/controller) passes.
• The rendered configuration was started with dolt sql-server 2.4.2.
  • The remotes API listened on 50052.
  • @@global.event_scheduler read OFF.
• On a UDS Core k3d cluster, a downstream project ran a build of v0.0.1 with
  this commit and both fields set (remotesAPI.port: 50052,
  behavior.eventScheduler: "OFF"). Its packaged browser suite cloned and
  pushed through the remotes API: clones fetched table files from it
  directly, and publications pushed to it through an authorizing proxy. The
  rendered /db/config.yaml kept both settings. No differences were observed
  (SHA-256 3b31d515…) between two reconciles of spec.env changes, each
  rolling the StatefulSet, an OOM-killed container restart and a deleted
  pod. @@global.event_scheduler read OFF after the deleted pod came
  back. Deploying the patched operator to that cluster left another,
  unchanged DoltDB alone: no roll, no restart, the same configuration.

The integration suite (make tiltci) was not run.

[coffeegoddd]

@realnedsanders thanks so much for the contribution! There were a couple places that needed shoring up, so I went ahead and picked up your commits and made the necessary changes in this pr, which will supersede this one: #20