Wrong burn value parsing in rpc.Transaction

[thlucy]

The parsing code in rpc.Transaction depends on the order of BalanceUpdates.
But I got some unexpected order from octez nodes.

For example, query the node by curl https://ithacanet.ecadinfra.com/chains/main/blocks/699996/operations/3/5 | jq '.contents[0].metadata.internal_operation_results[0].result.balance_updates'.

[
  {
    "kind": "contract",
    "contract": "tz1UA6Neo7pu6qvUveZQq1ZWwV1YuNgoip4m",
    "change": "-1750",
    "origin": "block"
  },
  {
    "kind": "burned",
    "category": "storage fees",
    "change": "1750",
    "origin": "block"
  },
  {
    "kind": "contract",
    "contract": "KT1Fea9sCJ4BKjEYHLoEja7JuhXxKZkv9XDp",
    "change": "-4000000",
    "origin": "block"
  },
  {
    "kind": "contract",
    "contract": "KT1A4KXaQfaGnyzGj5btMYgv77s5QxaMaANc",
    "change": "4000000",
    "origin": "block"
  }
]

The first and second result are about storage burn, but in current implementation of [rpc.Transaction:53](https://github.com/blockwatch-cc/tzgo/blob/master/rpc/transaction.go#L53

		if in.Amount > 0 {
			i += 2
		}
		if in.Result.PaidStorageSizeDiff > 0 {
			burn := in.Result.BalanceUpdates[i].Amount()
			cost.StorageBurn += -burn
			cost.Burn += -burn
			i++
		}

It will add 4000000 to the storage burn which is not correct, it is balance change.

[echa]

Thanks for the detailed report. Its a tricky issue to get right across all protocols (TzGo aims to be compatible for reading old protocol data and writing the latest mainnet protocol). The fix in v1.13.2 works with your example and a few other examples I tried, but it's no guarantee it'll work with all possible orders of balance updates. Please let me know if you find other issues regarding this function in the future. I may have to revisit the implementation again.