Metrics for query lifecycle

[ggevay]

This PR implements the next part of #32504, namely the following two metrics:

• parsing time
• processing time for the various pgwire messages to cover the Extended Query flow.

(I'm planning one more PR, which would add a metric for time between first result byte sent and last result byte sent. That one is somewhat less important, so I'd like to get just the above two merged first.)

Motivation

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[aljoscha]

Looks good, the test might get flaky if the machine we're running on is very overloaded. But we can fix that once we get there, I think.

[ggevay]

Ok, thank you!

the test might get flaky if the machine we're running on is very overloaded.

There is another test, workflow_test_optimizer_metrics, which uses the same idioms (assert 0 < time < 10 for some metrics related to query processing time), and I've never seen it flake, so this should hopefully be rare.