Allow longer timeout for starting pageserver, safe keeper and storage controller in test cases to make test cases less flaky

[Bodobolero]

Problem

see #8070

Summary of changes

the neon_local subcommands to

• start neon
• start pageserver
• start safekeeper
• start storage controller

get a new option -t=xx or --start-timeout=xx which allows to specify a longer timeout in seconds we wait for the process start.
This is useful in test cases where the pageserver has to read a lot of layer data, like in pagebench test cases.

In addition we exploit the new timeout option in the python test infrastructure (python fixtures) and modify the flaky testcase to increase the timeout from 10 seconds to 1 minute.

Example from the test execution

RUST_BACKTRACE=1 NEON_ENV_BUILDER_USE_OVERLAYFS_FOR_SNAPSHOTS=1 DEFAULT_PG_VERSION=15 BUILD_TYPE=release     ./scripts/pytest test_runner/performance/pageserver/pagebench/test_pageserver_max_throughput_getpage_at_latest_lsn.py
...
2024-06-19 09:29:34.590 INFO [neon_fixtures.py:1513] Running command "/instance_store/neon/target/release/neon_local storage_controller start --start-timeout=60s"
2024-06-19 09:29:36.365 INFO [broker.py:34] starting storage_broker to listen incoming connections at "127.0.0.1:15001"
2024-06-19 09:29:36.365 INFO [neon_fixtures.py:1513] Running command "/instance_store/neon/target/release/neon_local pageserver start --id=1 --start-timeout=60s"
2024-06-19 09:29:36.366 INFO [neon_fixtures.py:1513] Running command "/instance_store/neon/target/release/neon_local safekeeper start 1 --start-timeout=60s"

[github-actions]

3341 tests run: 3215 passed, 0 failed, 126 skipped (full report)

---

Flaky tests (3)

Postgres 16

• test_change_pageserver: debug
• test_secondary_background_downloads: release

Postgres 14

• test_subscriber_restart: debug

Code coverage* (full report)

• functions: 32.3% (6842 of 21153 functions)
• lines: 49.8% (53337 of 107157 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
cfd8645 at 2024-06-21T10:44:23.313Z :recycle:}

[hlinnaka]

No objections, but I wonder if this is just papering over the real issue:

This is useful in test cases where the pageserver has to read a lot of layer data, like in pagebench test cases.

Why does having a lot of layer data make the pageserver start up slow? There shouldn't be anything in the startup codepath that scales with the amount of data or # of layers, right?

[Bodobolero]

No objections, but I wonder if this is just papering over the real issue:

This is useful in test cases where the pageserver has to read a lot of layer data, like in pagebench test cases.

Why does having a lot of layer data make the pageserver start up slow? There shouldn't be anything in the startup codepath that scales with the amount of data or # of layers, right?

We discussed this on slack and agreed on increasing the timeout

[problame]

+1 for rust bits

[sharnoff]

(maybe off-topic, but why is autoscaling review requested?)

[Bodobolero]

(maybe off-topic, but why is autoscaling review requested?)

good question, I did not explicitly request it, maybe some code ownership rules of affected files?