Allow overriding the vtbackup data volume per tablet pool (#661)

[mcrauwel]

Summary

Fixes #661.

This change adds an optional, shard-scoped vtbackup block to VitessShardTemplate. The block is a sibling of tabletPools and controls the scratch data volume used by vtbackup Pods for that shard.

Historically, vtbackup Pods inherited the first tablet pool's dataVolumeClaimTemplate. That behavior allocates a PVC and an underlying disk per shard, even for the initial backup of an empty database. Large clusters can therefore allocate substantial unused storage or fail to bootstrap when those PVCs cannot bind.

Configuration

An empty vtbackup block lets the initial backup use ephemeral scratch space while tablet Pods retain their normal PVCs:

spec:
  keyspaces:
  - name: commerce
    partitionings:
    - equal:
        parts: 2
        shardTemplate:
          vtbackup: {}
          tabletPools:
          - cell: zone1
            type: replica
            replicas: 3
            dataVolumeClaimTemplate:
              accessModes: [ReadWriteOnce]
              resources:
                requests:
                  storage: 100Gi
            vttablet: {}
            mysqld: {}

A shard can instead provide a dedicated PVC template for vtbackup Pods:

vtbackup:
  dataVolumeClaimTemplate:
    storageClassName: cheap-disk
    accessModes: [ReadWriteOnce]
    resources:
      requests:
        storage: 10Gi

Semantics

vtbackup configuration	Initial backup	Scheduled backup
Block omitted	Inherits the first tablet pool's PVC template	Inherits the first tablet pool's PVC template
Block present, template omitted	Uses ephemeral emptyDir scratch space	Inherits the first tablet pool's PVC template
dataVolumeClaimTemplate set	Uses the vtbackup-specific PVC template	Uses the vtbackup-specific PVC template

Scheduled backups keep persistent scratch storage when the block is empty because vtbackup restores the latest full database before taking a new backup. Using an unbounded emptyDir for that workload could cause node disk pressure or eviction.

Omitting the block preserves the historical behavior. Tablet Pod storage is unaffected.

Storage reconciliation

The operator records a hash of the effective vtbackup PVC template on the initial-backup Pod and PVC. When the storage configuration changes, it:

1. Preserves a running initial-backup Pod.
2. Recreates a non-running initial-backup Pod.
3. Replaces its PVC only after the old Pod is gone.

This allows the controller to converge across PVC-to-emptyDir, emptyDir-to-PVC, and custom-PVC-template changes. In particular, adding vtbackup: {} can recover an initial backup that is Pending because its inherited PVC cannot bind.

Scope

This change only separates vtbackup data-volume configuration from tablet storage. Broader vtbackup Pod overrides can build on the shard-scoped vtbackup block in follow-up work.

Tests

• Unit coverage for inherited, empty, and custom templates on initial and scheduled backups.
• Scheduled-backup coverage confirming that an empty vtbackup block still creates and mounts a PVC.
• Reconciliation coverage for PVC-to-emptyDir, emptyDir-to-PVC, and custom-template transitions.
• Coverage confirming that storage changes do not interrupt a running initial backup.
• Integration coverage confirming that vtbackup: {} removes the initial-backup PVC while tablet Pods retain theirs.
• Generated CRDs, deepcopy code, and API reference documentation are updated.

Local verification:

• make unit-test
• Changed-line golangci-lint: 0 issues
• VitessCluster integration test package compiled successfully