test: add regression test framework with CI for contributors

[rophy]

Motivation

I know that OLR has a "private, proprietary test suite with 1,000+ edge-case scenarios", which is nice.

This PR is NOT meant to replace existing test coverage. Instead, just to provide a basic safety net for contributions.

This PR adds a lightweight regression test framework that:

• Gives contributors or forked projects a way to verify changes locally
• Gives author (bersler) and contributors a way to know whether pull requests breaks something basic, via automated CI checks.

What's included

• Fixture pipeline (generate.sh): captures redo logs + golden output from a live Oracle instance
• Parameterized gtest (test_pipeline.cpp): replays captured redo logs against golden files — no Oracle needed at test time
• 2 Oracle environments: Free 23ai and XE 21c, with some basic SQL test scenarios
• GitHub Actions workflows:
  • sql-tests-*: spins up Oracle in Docker, runs SQL scenarios, captures redo logs and golden output as artifacts. Runs on pushes to the test branch.
  • redo-log-tests: downloads the captured fixtures, builds OLR, replays redo logs and compares output against golden files. Runs on PRs — no Oracle needed.

See how the GHA workflows work in my fork: Redo Logs Test, SQL Tests against Free 23ai

Workflow for contributors

1. Make changes to OLR
2. Run tests locally (replays pre-built fixtures, no Oracle needed)
3. Open PR → GitHub Actions runs regression tests automatically
4. Optionally generate new fixtures with a running Oracle instance

[rophy]

@bersler I have been using Debezium + LogMiner in my corporate envs for quite some time, and like everyone else that came to you, I am evaluating whether the envs can benefit from integrating with OLR.

Reading the "Important Note on AI-Generated Patches and Forks" section in README, I guess you likely have received some AI-made contriutions without proper verifications, and likely asked or expected YOU to do the verification.

Having a test framework backed with public visible CI pipeline helps in the way that you can request contributors to contribute in the form of test cases. Hope that helps.

Disclaimer: this PR is created by AI (Claude) as well. I did not take a careful look at the test cases, but they look basic enough, and being docker-based helps to have consistent results across everyone's machine.

[Alex-pvl]

We're trying to understand the intended split between the two, because right
now they look like duplicated logic.

As far as we can tell:

• generate.sh brings up Oracle, runs the SQL scenario, captures the redo
  logs, and once produces the reference by running OLR and comparing its
  output against LogMiner.
• test_pipeline.cpp then re-runs OLR on those same redo logs and
  compares the result line-by-line against that reference.

So the actual OLR-on-redo run is done twice against effectively the same data.
It would make sense if test_pipeline.cpp were a standalone regression test —
i.e. commit the 3-generated/ fixtures and run only test_pipeline.cpp (no
Oracle, no LogMiner) on every change. But as it stands it's a mix: the C++
runner needs the fixtures freshly generated by the Oracle-backed generate.sh
each time, so it doesn't really stand on its own.

Question: what was the intended division of responsibility here? Was
test_pipeline.cpp meant to be the real regression gate (with committed
fixtures, runnable without Oracle), or is the LogMiner comparison inside
generate.sh already the source of truth? Right now the same thing runs in
both places and we'd like to remove the duplication — which direction did you
have in mind?