config: remove shard_local_cfg checks for tombstone_retention_ms validator

[WillemKauf]

These checks are invalid, as cluster config changes are applied one by one. A user could edit multiple properties at once to a valid state, and be caught by this attempted validation with an outdated value in the shard_local_cfg().

Multi-property validation of this cluster property is already handled in server.cc, see config_multi_property_validation().

Backports Required

• none - not a bug fix
• none - this is a backport
• none - issue does not exist in previous branches
• none - papercut/not impactful enough to backport
• v24.3.x
• v24.2.x
• v24.1.x

Release Notes

• none

[vbotbuildovich]

CI test results

test results on build#61414

test_id	test_kind	job_url	test_status	passed
rptest.tests.archival_test.ArchivalTest.test_single_partition_leadership_transfer.cloud_storage_type=CloudStorageType.ABS	ducktape	https://buildkite.com/redpanda/redpanda/builds/61414#0194b992-9b26-4762-b032-4e862eca9ba8	FLAKY	1/2
rptest.tests.cloud_storage_scrubber_test.CloudStorageScrubberTest.test_scrubber.cloud_storage_type=CloudStorageType.S3	ducktape	https://buildkite.com/redpanda/redpanda/builds/61414#0194b992-9b28-4291-bb07-73f670852ab3	FLAKY	1/2
rptest.tests.compaction_recovery_test.CompactionRecoveryTest.test_index_recovery	ducktape	https://buildkite.com/redpanda/redpanda/builds/61414#0194b997-9dd8-4dc1-b163-cb9e514b5f31	FLAKY	1/2
rptest.tests.compaction_recovery_test.CompactionRecoveryUpgradeTest.test_index_recovery_after_upgrade	ducktape	https://buildkite.com/redpanda/redpanda/builds/61414#0194b992-9b28-4291-bb07-73f670852ab3	FLAKY	1/2
rptest.tests.compaction_recovery_test.CompactionRecoveryUpgradeTest.test_index_recovery_after_upgrade	ducktape	https://buildkite.com/redpanda/redpanda/builds/61414#0194b997-9dd5-45ee-9f49-4b289523b707	FLAKY	1/2
rptest.tests.datalake.datalake_e2e_test.DatalakeE2ETests.test_topic_lifecycle.cloud_storage_type=CloudStorageType.S3.filesystem_catalog_mode=True	ducktape	https://buildkite.com/redpanda/redpanda/builds/61414#0194b992-9b27-47a3-a69f-a5de95dbec01	FLAKY	1/2

[andrwng]

Makes sense. The only way to update a cluster config is through the admin endpoint, right? So we're guaranteed to hit config_multi_property_validation?

[dotnwat]

Makes sense. The only way to update a cluster config is through the admin endpoint, right? So we're guaranteed to hit config_multi_property_validation?

same question. i think so, but what about on cluster create? i was thinking that an initial configuration file could be loaded directly (ie --redpanda-cfg cli arg)

[WillemKauf]

The only way to update a cluster config is through the admin endpoint, right? So we're guaranteed to hit config_multi_property_validation?

One could directly edit the config_cache.yaml file, and not hit config_multi_property_validation(). But this is advised against to begin with.

same question. i think so, but what about on cluster create?

Cluster properties should be ignored in the file specified by --redpanda-cfg if broker properties are also specified. But no, same response, we wouldn't hit config_multi_property_validation().

There are still some sanity checks for getting the value of tombstone_retention_ms from the ntp_config, so even in an unintended state we would be free from potential runtime issues, but perhaps there should be another call to config_multi_property_validation() during the bootstrap process to avoid the potential holes above.