xdrill transaction helper functions

[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 name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've reviewed the changes in this PR and if I consider them worthwhile for being mentioned on release notes then I have updated the relevant CHANGELOG.md within the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

github issue

xdrill functions for Transactions

Why

Helper functions for Transactions for processors/transforms from stellar-etl for history_transactions found here

Known limitations

• Refactor of the processor/transforms to be done in separate ticket/pr

[chowbao]

Similar problems from stellar#5568 exist in this PR as well

• pointer data types could be changed to (datatype, bool)
• utils package is bad practice
• look out for more existing functions within xdr and ingest

[sydneynotthecity]

Same comment here as the Ledgers PR. Is it worthwhile to be consistent in the use of GetThing() vs MustThing()? Whatever decision is made with ledgers should be applied here as well

[chowbao]

Same comment here as the Ledgers PR. Is it worthwhile to be consistent in the use of GetThing() vs MustThing()? Whatever decision is made with ledgers should be applied here as well

So it turns out that the Get/Must and what whether they return bool, error, or panic is already inconsistent within the existing xdr lol. Same comment as stellar#5568 (comment) for how we want to return bool, error, and panic in theory. In practice, for now I decided to propagate through the existing xdr return statuses.

I could force and ignore errors in favor of ok bool in this PR but I think I prefer propagating existing xdr return statuses and then holistically updating return statuses and behavior later

[sydneynotthecity]

I think inclusion fee (base fee) needs a second look. Otherwise should be good

[sydneynotthecity]

is it worthwhile to name this function SorobanInclusionFeeBid() so that users don't conflate classic <> soroban?

[chowbao]

updated in 24fcd92

[sydneynotthecity]

I think calculating the inclusion fee is a little more nuanced than this:

Fee Charged = inclusion fee * (operation count + if(fee_account is not null, 1, 0)

we want to know what that base fee was for the given txn since we can get the Fee charged from FeeCharged() function

[chowbao]

updated in 24fcd92

[sydneynotthecity]

looks good!

[chowbao]

closing in favor of the stellar/go PR stellar#5579