Persistence of proposal, transaction and commit objects

[bestbeforetoday]

As an application developer
I want to persist proposal, transaction and commit objects
So that I can resume a submit flow following an application restart

This is already possible using the off-line signing flow but the methods for re-creating these objects from serialized bytes do not make it obvious that this is the case, either through their naming or the presence of a signature parameter, which must be left empty for the persistence flow without off-line signing.

Suggest simply adding methods such as newUnsignedProposal(bytes) to Gateway to support this flow. The implementation would be largely common with the newSignedProposal(bytes, signature) methods.

[bestbeforetoday]

As we start working on this it's becoming obvious that, if the request being serialised (proposal, transaction, commit, block / chaincode events request) has already been signed using the off-line signing flow, the serialised form should include that signature and it should be preserved when deserialised. It would be unhelpful to require client applications to separately store the off-line signature or to repeat off-line signing if they choose to persist a proposal. This makes the newUnsignedProposal() naming a bit misleading. Typically it may be unsigned but there are cases where it may already be signed and we want to retain that signature.

To fit with the existing Gateway.newSignedProposal(bytes) naming, we could call the method used to deserialise a proposal from its bytes simply Gateway.newProposal(bytes). Or it could have a more descriptive name, something like Gateway.proposalFromBytes() or Gateway.deserializeProposal(). Anyone got any strong preferences?