protocols/horizon: Add memo_bytes field to transaction response

[tamirms]

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 updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• 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

Close #2458

Add memo_bytes field to the Horizon transaction response. memo_bytes contains the base64 encoding of the original byte sequence set in the transaction envelope's memo field.

Why

As noted in #2022 , the memo value in a transaction can be an arbitrary binary blob even if the memo type is text. When horizon ingests transactions, it tries to store the memo field as a utf8 string even if the memo value is not valid utf8.

The Java SDK tries to recover the original byte representation of the memo by decoding the XDR. See lightsail-network/java-stellar-sdk#259 . However, we would like to avoiding XDR decoding in the SDKs when deserializing Horizon responses. The XDR definitions are subject to change so the SDKs should be relying on Horizon's API to avoid manually parsing XDR.

If we can include a memo_bytes field in the Horizon transaction resource, which is present alongside the memo field when memo_type is "text", then the Java SDK can use memo_bytes to recover the original memo value without having to parse envelope_xdr.

Known limitations

[N/A]

[ire-and-curses]

LGTM

[ire-and-curses]

Could you also add a comment to the original memo line, so that the reader can understand the difference between the two?