Decide on use of int64 in JSON responses.

[abuiles]

This is a follow up of #1363 - we have multiple places where we return int64 in JSON responses, which could lead to issues in JS applications. We fixed the problem reported in #1363, but the question now is, should we do the same for the following struct and moving forward, does it make sense to avoid int64 on Horizon structs? We haven't been consistent with this.

• go/protocols/horizon/operations/main.go:139:10: OfferID int64 json:"offer_id"
• go/protocols/horizon/operations/main.go:146:10: OfferID int64 json:"offer_id"
• go/protocols/horizon/effects/main.go:260:20: OfferID int64 json:"offer_id"
• go/protocols/horizon/main.go:228:21: ID int64 json:"id"
• go/protocols/horizon/main.go:376:16: Timestamp int64 json:"timestamp"
• go/protocols/horizon/main.go:377:16: TradeCount int64 json:"trade_count"

[bartekn]

@abuiles can you update the Horizon 0.20.0 CHANGELOG with this list and add Action needed tags (for 0.22.0 release)?

[ire-and-curses]

Because of our imminent special v12 protocol release (Horizon 0.22), these fields are now scheduled to change in 0.23.

[ire-and-curses]

After internal discussion we're going to change all of these in Horizon 0.25, to give SDKs enough time to handle it.

[leighmcculloch]

Has a decision been made on this yet? I don't see a decision communicated here, but give SDKs enough time to handle it sounds like we've made one.

[ire-and-curses]

Yes. These fields will change to string. We'll be raising issues with all the SDKs (ours + community). We'll aim to support the fields both before and after the change with the next SDK version, so that the Horizon update won't cause clients to break at a discrete point in time.

[abuiles]

Fixed on #2021