protocols/horizon: Add custom UnmarshalJSON to struct with int64 fields.

[abuiles]

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

Add UnmarshalJSON to Trade, this method supports parsing of int64 fields as as json.Number which might be a string or int64. This will allow us to cut a new release for the horizon client which won't break once we change the data type on the JSON payload.

Why

Using Int64 in JSON payloads produces inconsistent results in JS (see #1363).

We are in the process of updating all the int64 JSON fields to be of type string. The idea with this change is to extend the Unmarshal function to take either int64 or string, that way we can release a version of the horizon client which won't break once the payload changes in the API.

See #1609, #1909 and #1912

Known limitations

[TODO or N/A]

[bartekn]

I'm wondering if this PR is only for horizon client release can we:

1. Recreate it on top of master.
2. Set the base branch to a release branch of horizon client.
3. Instead of creating custom UnmarshalJSON, just use json.Number where needed.
4. After releasing horizon client do not merge it into master (yet).
5. Merge the release branch when Horizon 0.25.0 is released.

This will make this code much less complicated, however, it will be easy to introduce regression bug (ex. new horizon client release from a branch branched off master without this commit).

[tamirms]

@abuiles should this PR be merged into the horizonclient 2.0.0 release branch instead of the 0.24.0 horizon release?

[abuiles]

@bartekn

Instead of creating custom UnmarshalJSON, just use json.Number where needed.

If we use json.Number wouldn't that be changing the type to json.Number instead of int64? It would be a breaking change for users, since they'll have to change their code to call .Int64()

[bartekn]

@abuiles You're obviously right! I though that json.Number is int64 but it's string.

[leighmcculloch]

We could make our own int64 type that acts like json.Number in regards to strings but it would still be a breaking change because an importer would need to explicitly cast from our type to the int64 type they're already using.

[abuiles]

We could make our own int64 type that acts like json.Number in regards to strings but it would still be a breaking change because an importer would need to explicitly cast from our type to the int64 type they're already using.

Exactly, that's what we are trying to achieve with this. We want to make it transparent to final users that the type changed in the payload, but keep it as an int64 in Go.

[abuiles]

@tamirms I squashed all the related commits and updated the branch, PTAL :)

[abuiles]

@tamirms updated the trade struct following your recommendation. Thanks!