Pass through change updates to change compactor

[chowbao]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with the jira ticket associated with the PR.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated the README with the added features, breaking changes, new instructions on how to use the repository. I updated the description of the fuction with the changes that were made.

Release planning

• I've decided if this PR requires a new major/minor/patch version accordingly to
  semver, and I've changed the name of the BRANCH to major/_ , minor/_ or patch/* .

What

Github issue

Moving a copied version of the changeCompactor with the new Change struct fields into stellar-etl to pass through transaction_id, operation_id, and operation_type to ledger entry changes

Why

To get more useful join keys in the ledger entry change tables in BQ

Known limitations

• transaction_id, operation_id, and operation_type may not be entirely correct because we are using compacted changes where we keep the data for the latest change within a ledger. This should be fixed when stellar-etl is moved off of using changeCompactor and the ledger entry change table saves all changes instead of compacted changes
• Some of this plus simpler logic could be used depending on Update the ingest/change Change struct to always pass LCM if available go#5578

[socket-security]

Updated dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
golang/github.com/dgryski/[email protected] 🔁 golang/github.com/dgryski/[email protected]	None	0	84.6 kB
golang/github.com/stellar/[email protected] 🔁 golang/github.com/stellar/[email protected]	None	0	15.5 MB

View full report↗︎

[chowbao]

One other important note. This requires a schema change for the raw tables. I think it'd be worthwhile to have this run in the test airflow over the weekend if possible

[sydneynotthecity]

I think it'd be worthwhile to have this run in the test airflow over the weekend if possible

Yup, agreed. I also think we should modify the dune exports and drop these new columns and determine whether or not it's necessary to propagate into dune. If our end goal is to create a token_transfers table there, i don't think it's worthwhile to add to external facing warehouses.

[sydneynotthecity]

Looks good, i didn't review the golden files and just assume they implicitly work based on tests passing