adapter,persist: make TCP keepalives configurable for CRDB connections

[teskje]

... and make it much more aggressive than the default two-hour interval.

This is required to make CRDB clients detect broken idle connections within a time frame of less than two hours.

With this PR, the repro in https://github.com/MaterializeInc/database-issues/issues/10019#issuecomment-3759914521 shows persist becoming functional again after 10s (the time until the first keepalive probe is sent) instead of after 2 hours.

Motivation

• This PR fixes a recognized bug.

Fixes https://github.com/MaterializeInc/database-issues/issues/10019

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.

[def-]

Should we wire up your pgwire-proxy into a regression test?

[teskje]

Should we wire up your pgwire-proxy into a regression test?

I don't think that's possible without a bunch of extra work!

• It's entirely vibe coded, so it'd definitely need a manual cleanup pass.
• It only works on macOS due to its dependency on pf. Should be easy to support iptables as well, but I'm not sure how well that fits into a Docker workload.
• It's also an awful lot of code to add for just a single regression test.

It'd be cool if there was a more general test framework that could catch these kinds of issues. I considered turmoil, but it doesn't simulate TCP down to the level of keepalives.