docs: clarify that mysqld.configOverrides also applies to vtbackup pods

[rajtherengan]

"Relates to vitessio/vitess#21228"

What this does

Clarifies the mysqld.configOverrides field doc comment to explicitly
note that these overrides also reach vtbackup Pods, not just regular
vttablet/mysqld instances.

Why

This came up in vitessio/vitess#21228, where a user was looking for a
way to set custom mysqld config (specifically innodb_redo_log_capacity)
for vtbackup Pods. The functionality already exists via
mysqld.configOverrides — confirmed by tracing extraMyCnf.Add(...) in
mysqld_config_overrides.go, which explicitly appends the same override
file for vtbackup (vtbackupExtraMyCnfFile) — but this wasn't
discoverable from the field's doc comment alone.

No functional changes; doc comment only, regenerated docs/api.md and
docs/api/index.html via make generate.

[mattlord]

1. Blocking: I think that we should say that the overrides come from the first tablet pool only. In pkg/apis/planetscale/v2/vitessshard_types.go:347, the new sentence says the overrides reach "any vtbackup Pods spawned for this tablet pool's shard", which reads as if every pool's configOverrides applies. Both the initial backup (pkg/controller/vitessshard/reconcile_backup_job.go) and the scheduled backups (vitessbackupschedule_controller.go:803) build their Pod through MakeVtbackupSpec, which takes its spec from vts.Spec.TabletPools[0] (reconcile_backup_job.go:266-269). With a replica pool and an rdonly pool, for example, only the first pool's overrides reach vtbackup, and someone setting innodb_redo_log_capacity on the second pool based on this comment would see it silently ignored. Since the point of this PR is to make the behavior discoverable, I think that we should say something like "vtbackup Pods for this shard, both initial and scheduled backups, use the mysqld settings of the first tablet pool in the shard spec, including these overrides". No? I also wonder if that's not at least part of what is behind the issue this is in response to.

2. Non-blocking: I wonder if we should mention the two settings vtbackup always overrides. mysqld_config_overrides.go appends vtbackup.cnf after /pod-config/mysqld-config-overrides so that it wins, and the vtbackup init script writes sync_binlog=0 and innodb_flush_log_at_trx_commit=0 into it (pkg/operator/vttablet/vtbackup_pod.go:49). Anyone overriding those two for backup jobs would find their values ignored. A short "except sync_binlog and innodb_flush_log_at_trx_commit, which vtbackup sets itself" would keep the doc accurate.

Thanks for tracing this down from the upstream question, this is a good one to have in the API docs! 🙏

[rajtherengan]

Good catch on both — you're right that the original wording implied every pool's overrides apply, which isn't accurate and could actively mislead someone with multiple tablet pools. And yes, this may well explain part of the confusion behind the original issue.

Updated the comment to:

ConfigOverrides can optionally be used to provide a my.cnf snippet
to override default my.cnf values (included with Vitess) for this
particular MySQL instance. vtbackup Pods for this shard, both
initial and scheduled backups, use the mysqld settings of the
first tablet pool in the shard spec, including these overrides,
except for sync_binlog and innodb_flush_log_at_trx_commit, which
vtbackup always sets itself.

Pushed in the latest commit — let me know if that captures it accurately or if I'm still missing a nuance.

[mattlord]

LGTM! Thanks, @rajtherengan ! ❤️

Does this resolve the issue for you @jwangace ? If not, then please go into more detail in the issue on what you think is needed and why. Thanks!