CBG-5702 replace WaitForCondition test helpers for dbconfig

[torcolvin]

CBG-5702 replace WaitForCondition test helpers for dbconfig

Remove WaitForCondition with testify helpers which give better output.

Integration Tests

• https://jenkins.sgwdev.com/job/SyncGatewayIntegration/1045/

[factory-droid]

Droid finished @torcolvin's task —— View job

---

[Copilot]

Pull request overview

Updates Sync Gateway’s REST test harness and related tests to replace custom WaitForCondition* polling (used around dbconfig/config-polling scenarios) with testify’s EventuallyWithT-style helpers for clearer failure output and less bespoke polling logic.

Changes:

• Added RestTester.WaitForDatabase and RestTester.WaitForInvalidDatabase helpers built on require.EventuallyWithT.
• Refactored several dbconfig/config-polling tests to use the new helpers (and EventuallyWithT/Never directly in a couple spots).
• Relaxed ServerContext.AllInvalidDatabaseNames’s testing-only signature from *testing.T to testing.TB.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
rest/utilities_testing.go	Adds new RestTester wait helpers and adjusts AllInvalidDatabaseNames to accept testing.TB.
rest/config_test.go	Switches invalid-db polling from inline EventuallyWithT to rt.WaitForInvalidDatabase.
rest/adminapitest/resync_test.go	Replaces a generic “any db exists” poll with rt2.WaitForDatabase("db").
rest/adminapitest/admin_api_test.go	Refactors multiple config-polling/invalid-config waits to use the new helpers and EventuallyWithT.

Suppressed comments (3)

rest/adminapitest/admin_api_test.go:1205

• This call waits for "db1" to be tracked as invalid, but the previous logic required exactly one invalid database config. If that's still the intended invariant for this scenario, keep the count check to prevent the test passing with unexpected extra invalid configs.

	rt3.WaitForInvalidDatabase("db1")

rest/adminapitest/admin_api_test.go:1273

• This wait no longer asserts that there is exactly 1 invalid database config (it only checks presence of "db1"). If the test expects a single invalid config here, add a length assertion to preserve the original check and avoid masking additional invalid configs.

	rt3.WaitForInvalidDatabase("db1")

rest/adminapitest/admin_api_test.go:1334

• This now only waits for "db1" to appear as invalid; previously the test asserted there was exactly one invalid database. If that strictness is still desired, add a length assertion so the test fails when additional invalid configs are present unexpectedly.

	rt.WaitForInvalidDatabase("db1")

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[factory-droid]

Change is a straightforward refactor from bespoke wait loops to testify-based helpers and adds RestTester convenience methods. No concrete, actionable bugs found in the diff.