fix(pageserver): add the walreceiver state to tenant timeline GET api endpoint

[duguorong009]

Add a walreceiver_state field to TimelineInfo (response of GET /v1/tenant/:tenant_id/timeline/:timeline_id) and while doing that, refactor out a common Timeline::walreceiver_state(..). No OpenAPI changes, because this is an internal debugging addition.

Fixes #3115.

[koivunej]

Otherwise this is looking good but I see I have failed to update the issue description and only requested this in my follow-up comment much later.

Could you move it to be part of pageserver::http::routes::timeline_detail_handler or GET /v1/tenant/:tenant/timeline/:timeline instead of a new endpoint? In pratice with prod, timeline detail is what we most often get, that way it would be easily accessible for all "existing users".

[duguorong009]

Otherwise this is looking good but I see I have failed to update the issue description and only requested this in my follow-up comment much later.

Could you move it to be part of pageserver::http::routes::timeline_detail_handler or GET /v1/tenant/:tenant/timeline/:timeline instead of a new endpoint? In pratice with prod, timeline detail is what we most often get, that way it would be easily accessible for all "existing users".

@koivunej
I updated the PR as you recommend. (Thanks for tips!)
Please re-check the PR, and give me the comments.

[koivunej]

Yeah apologies on the openapi changes, which were good but as we'll need this for debugging, I don't think it is important to note this here.

Let's make the new methods pub(crate) and I'll fire up a workflow run for this. I can most likely merge those commits, let's try.

[koivunej]

Thanks for working on this as well!

I added those pub(crate) and can fix up if these cause any issues. pub(crate) will make it visible (compiler warning) if these functions were to become unused later.

Hmm.. Looks like I don't have to make a separate workflow for this now that I've commited to it, which is nice. Nope, still need to create one, but will handle that after seeing that my suggestions still compile.

[duguorong009]

Thanks for the fixture commit! @koivunej

BTW, can you check the issue #5131 and give some comments?
Or, at least, you let @problame know?
Thanks in advance!

[duguorong009]

Thanks for working on this as well!

I added those pub(crate) and can fix up if these cause any issues. pub(crate) will make it visible (compiler warning) if these functions were to become unused later.

Hmm.. Looks like I don't have to make a separate workflow for this now that I've commited to it, which is nice. Nope, still need to create one, but will handle that after seeing that my suggestions still compile.

Yes, for me, the CI run is a bit inconvenient.
Also, I just do the cargo test for local testing of PR.

[koivunej]

Yes, for me, the CI run is a bit inconvenient. Also, I just do the cargo test for local testing of PR.

It's a bit inconvenient for everyone, but especially for external contributors :) cargo test is fine with rust tests.

Python tests take quite some time and requrie a beefy cpu, preferably an isolated box. I usually run them with ./scripts/pytest -n16 -vv --tb=short -k 'debug-pg14' after a cargo build_testing, but ... for these rust refactorings there should be no need.