Client needs to be able to make sure that we have the latest State Proof

As of now, Results with state proofs contain the time when transaction was written to the Ledger.
It may be enough for some of the cases, but in general we also need to make sure that a Node returned a State Proof for the latest state. It's especially critical if we get reply from one node only, and this node can be malicious.

Example:

• There is a NYM with seqNo 10 and time X. Then the key was rotated in a NYM with seqNo 20 and time Y.
• We send GET_NYM to a node willing to get the latest key.
• But the Node is malicious, and returns result as it was at the time X and seqNo 10. A client doesn't know if this is the latest state or not.

Possible solution:

• we need to sign not only domain and pool state roots as of now, but also the timestamp of this state (and possibly seqNo as well).
• so, we create multi-signature over `state_root_hash+txn_root_hash+pool_state_root_hash+state_ts+ledger_id`
• include domain_state_ts and domain_state_last_seqNo into State Proof with each Reply
• With this approach, once client receives a Reply, he validates the multi-signature (against returned `state_root_hash+txn_root_hash+pool_state_root_hash+state_ts+ledger_id`). So, a client can be sure that the result is not older than specified timestamp.
  The client can later decide if the transaction is fresh enough for him. If not, he can ask another Node (another Observer for example), or fall back to f+1 replies.

The proposed solution can not guarantee that the result is really the latest one (but actually we can not guarantee it in general in BFT system, especially once we introduce Observer Nodes). But the provided information should be enough for the client to decide of the returned result is fresh enough for him.