24-host: Reduce provable surface area to only packet flow keys

[AdityaSripal]

• Removes connection/channel keys
• Client keys are now private since they aren't proven by counterparty
• Keeps key paths and values the same for now
• Add counterparty key/value to private store
• Remove self client validation necessity

Context for Reviewers:

This PR introduces a new high level packet and acknowledgement commitment.

• The packet commitment must now include the destination identifier

• The packet commitment hashes the destination identifier, timeout, and app data all as bytes to create a fixed preimage size and then hashes the result

• The acknowledgement is just a hash of the acknowledgement

Closes: #1138

[crodriguezvega]

Looks good to me!

[crodriguezvega]

Just curious: why was this section deleted?

[sangier]

That's a great simplification!!! If you merge latest change from feat/v2-spec you should be able to get rid of the CI failures.

[AdityaSripal]

Leaving open for now because we may want to remove specification of private keys entirely. it is up to individual implementations to decide how best to execute the logic required to write the provable keys in store.

Also, we should be standardizing the values stored under the provable keys in this specification as well.

Also blocked on discussion around spec format. i.e. ABI for universal data format and moving to IETF standards for specs

[sangier]

Would be nice to have a visual representation of this

[sangier]

I'm wondering if there is some space for commitment collision which could led to double usage, but I cannot really think of a scenario that would allow that. At a first glance the provableStore paths look good to me.

[damiannolan]

Looks like we're missing "nextSequenceSend/ports/{identifier}/channels/{identifier}"?

I guess it doesn't need to be provable, but it should also still be defined?? I think we still want the logical separation of sequence/nonce under its own key in v2. And the current impl still relies on port identifier being included

[sangier]

Since it won't be provable, but the ICS4 still uses it, I have defined the

function nextSequenceSendPath(sourceChannelID: bytes): Path {
    return "nextSequenceSend/{sourceChannelID}"
}
``` in the privateStore. However,  being local and private it could be any path that the chains want to set, thus I guess the implementation should be able to avoid relying on the port, correct?  

[sangier]

seems that sequences will be the main discriminator here, thus would be possible to use a path like "receipts/{identifier}/sequences/{bigEndianUint64Sequence}" so deleting the channels reference?

[AdityaSripal]

Merging this though the key paths may still be subject to change. Avoiding having PRs stand up for too long