vstreamclient: framework for robust + simple usage

[derekperkins]

Description

Proof of concept implementation for #17221.

Currently, the test file requires the local example to be running, and only succeeds on the first run. Once the overall concept and framework are in a good place, I'll add in better testing for CI. There are a lot of test helpers available in the vtgate/vttablet packages that aren't available to me here. It may end up being easier to just add the tests to one of those suites, rather than trying to build an E2E framework in this package.

Code Walkthrough

Related Issue(s)

• Fixes RFC: VStream client reference implementation #17221

Checklist

• "Backport to:" labels have been added if this change should be back-ported to release branches
• If this change is to be back-ported to previous releases, a justification is included in the PR description
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on CI?
• Documentation was added or is not required

Deployment Notes

Currently runs on the local example setup, per the instructions here: https://vitess.io/blog/2024-07-29-cdc-vstream/#a-look-under-the-hood-at-vstream. Will migrate tests once the RFC is accepted and location is decided on.

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.

[rohit-nayak-ps]

Overall it looks very good. I have mentioned some issues below. Once we address those, and whatever you feel are needed as part of this, we should merge and address the several TODOs noted in the future.

I am still undecided about where to locate it. I will let others weigh in here.

I had some issues running the unit tests:

• I had to drop the state table before running TestVStreamClient for the second time. 
• I could only run one of the tests at a time. Looks like the first test doesn't clean up the state and hence the second fails, if I just run go test. Also it will be good to name TestVStreamClient to TestVStreamClientBasic or some such to make it easier to run each test separately
• I think it might be easier not to require the state table by default (or provide some mechanism to clean it up either by default or by setting a flag separately). We could store the state locally for the duration of the test in-memory. Maybe if we fix the previous issues this may not be necessary though ...
• It is difficult to debug this in an IDE because of different short timeouts. While trying to figure out some local failures various contexts kept expiring even after setting a few of the values to high numbers. Not sure what the best solution for this is: maybe move all timeout constants to a common place so anyone developing/debugging can modify it there. Maybe this is just needed for the initial phase, but others who fork this might also run into it while testing their changes.

Also:

• We can just send "" as the vgtid to start with the copy phase. No need to generate the per-shard vgtid done in New()
• We should also get the failing tests working. Maybe it just needs a rebase. If not, let us know if you need help with any eventual failing tests.
• Not sure if you had a look at the e2e tests in go/test/endtoend/vreplication. Those allow creating a cluster if you wanted to create an e2e test for this.
• Can you explain the specific tests for which you wanted to use non-exported functions from vtgate/vttablet. go/test/endtoend/vreplication has tests where entire clusters are created. Do those help?