sdk/state: give close agreements identifiers separate to their iteration number

[leighmcculloch]

I think we need to give close agreements identifiers that are separate to their iteration number. The iteration number is related to where in the history of the channel the close agreement exists. The value is an indicator of the state of the channel, from the proposer's perspective, that came prior but it doesn't provide any uniqueness. As part of the problem described in #287 it is likely that we need some way to uniquely identifier payments. This is also something @nikhilsaraf called out early that we need a unique identifier for a payment, based off what he saw in research of other payment channel designs.

Given that the close agreement is ultimately rendered as a set of transactions, I think the simplest method for constructing an identifier would be to concatenate the transaction hashes from the transaction set in a predefined order, e.g. declaration then closing, using the same hash function that Stellar uses for its transaction hashes, i.e. SHA-256. The result will be unique not only for an iteration number but for the agreement captured in the transactions that get built.

Alternatively we could construct a payload to hash off the close details, but that seems like more work with no benefits that I can see, other than we could include peripheral information like payment amount that aren't captured in the transactions.

This will be required for #338.

Refs:

• Handle concurrent payments #287
• Horizontal scaling within a serial payment channel #330
• examples/benchmarks: experiment with a merging channel #338