tests: Increase timeout in test_create_churn_during_restart

[hlinnaka]

This test was seen to be flaky, e.g. at
https://neon-github-public-dev.s3.amazonaws.com/reports/pr-9457/11804246485/index.html#suites/ec4311502db344eee91f1354e9dc839b/982bd121ea698414/.
If I reduce the timeout from 10s to 8s on my laptop, it reliably hits that timeout and fails. That suggests that the test is pretty close to the edge even when it passes. Let's bump up the timeout to 30 s to make it more robust.

See also #9730, although the error message is different there.

[github-actions]

5382 tests run: 5162 passed, 0 failed, 220 skipped (full report)

---

Flaky tests (3)

Postgres 17

• test_deletion_queue_recovery[no-validate-lose]: release-x86-64
• test_readonly_node_gc: debug-x86-64
• test_tenants_many: debug-x86-64

Code coverage* (full report)

• functions: 31.8% (7891 of 24834 functions)
• lines: 49.5% (62454 of 126257 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
2e14322 at 2024-11-13T00:27:49.319Z :recycle:}

[jcsp]

In the log linked, a timeline creation takes 5 seconds. I can see how that happens in CI when nodes are very overloaded, I'm a bit surprised it was readily reproducible on a (presumably fast) local laptop.

[hlinnaka]

In the log linked, a timeline creation takes 5 seconds. I can see how that happens in CI when nodes are very overloaded, I'm a bit surprised it was readily reproducible on a (presumably fast) local laptop.

Not a very fast laptop, and I compile in debug mode, and using cranelift which probably creates even slower binaries :-).

[jcsp]

think there may be a real bug here, but don't mind bumping the timeout in the interim:
#9730 (comment)