Fixed transaction signatures order.

[zorba128]

Improved Message to support external signers.
Also some refactorings be able to use it outside of Transaction/TransactionBuilder.

[zorba128]

Also updated Transaction/TransactionBuilder signature handling to ensure correct signature order. This should make it possible to correctly sign non-trivial transactions that involve multiple instructions/accounts.

[zorba128]

Any chance? Or maybe discussion? This is really broken, with transaction that requires few signatures it is impossible now to guess what to pass to sign method... Just try to make transaction with memo and few different token transfers.

[freedombird9]

@zorba128 It still requires signers when transaction.serialize(). If no signer is set, it throws RuntimeException("Missing signer for account " + publicKey). I don't understand how this commit sovles the issue.

[zorba128]

1. At least you know which signature is missing, rather than cryptic null pointer exception
2. The thing here is to allow specifying signatures without messing up account order in the transaction. In original design signing affected accounts, making it hard/impossible to reason about outcome, and often yielding invalid transactions.
   This comes into play when using tokens (with main account to be used for fee is different than source account). Or memo.

[freedombird9]

@zorba128 Yes, much appreciated. I further modified it to serialize without any signature, making external sign possible:

           // if signers is empty 
           int signaturesSize = 0; // No signatures
           byte[] signaturesLength = ShortvecEncoding.encodeLength(signaturesSize);
           int totalSize = signaturesLength.length + serializedMessage.length;
           ByteBuffer out = ByteBuffer.allocate(totalSize);
           out.put(signaturesLength);
           out.put(serializedMessage);

           return out.array();