Support for the out-of-band and did-exchange protocols

[Tangelo1]

Summary of changes:

1. Two new cases to test both main flows in the out-of-band protocol.
   • The sender flow -- I create an invitation and you use it
   • The receiver flow -- You create an invitation and I use it
2. Support for the out-of-band handshake reuse protocol.
   • This includes a new message handler to accept and respond appropriately
     3. Support for the did-exchange protocol.
        • You will now be able to complete a did-exchange flow between the AUT and the suite.
        • There is no new test case that explicitly completes this flow, but it is used within the OOB protocol test if specified in the AUT's handshake_protocol list.
3. Support for sending messages with https://didcomm.org/ in their @type field instead of did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/
   • Receiving a message with did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/ is still supported however.

NOTES:

• Request attach handling is not supported quite yet.
• During the receiver flow, we only handle the first supported handshake protocol. If that one fails, we don’t retry with the next one.

[lgtm-com[bot]]

This pull request introduces 4 alerts when merging fcf4057ffde7a85f8298eadedf6c3199f045747d into 27003be38beb254090e7708c4e45c99f42303571 - view on LGTM.com

new alerts:

• 2 for __eq__ not overridden when adding attributes
• 2 for Unused local variable

[lgtm-com[bot]]

This pull request introduces 4 alerts when merging 242faf320e3a0534e561975dc2a21ac7c9716cab into 27003be38beb254090e7708c4e45c99f42303571 - view on LGTM.com

new alerts:

• 2 for __eq__ not overridden when adding attributes
• 2 for Unused local variable

[Tangelo1]

@smithbk With regard to your trust ping comments -- I think the did-exchange complete would be sufficient to test the connection, but I'm wondering what we should do in the case that the AUT doesn't want to use did-exchange and chooses to use the connections protocol instead. I think in this case, without something like a trust ping there'd be no real way to verify the connection. Open to ideas for this, but I had originally put in the trust pings following how it's done by the current code. I've removed them for now, but I think we definitely need a method to verify the connections. Also I've re-read the OOB spec and it doesn't seem there's an explicit way to discover features in it.

[Tangelo1]

@smithbk With regard to the message prefixes. I've centralized the prefix definitions into the Suite class. When the time comes we can make these types such that the Suite.TYPE_PREFIX and Suite.ALT_TYPE_PREFIX to be the same. This effectively makes the suite only support the one prefix.

[smithbk]

@Tangelo1 IIRC, the connection protocol has an ACK message which would be equivalent to the DID exchange complete message. WRT the current code, yeh, I think an early version of the connection protocol may have said or recommended using the trust ping protocol to complete the connection. Also, the trust ping protocol used to be part of Aries Profile V1 but was removed. Obviously APTS wasn't updated appropriately.

Yeh, I was misremembering about OOB having features. If you wanted to do a trust ping, I think the proper way is that the trust ping request is added to the OOB message as an attachment. The receiver of the OOB message would optionally process the attachment and send the trust ping response. That said, I don't think it is necessary. Given that we could use the ACK message for the connection protocol and the complete message for the DID exchange protocol, I think it is sufficient to verify that the connection was successful.

[Tangelo1]

@smithbk Yep, you're correct. I forgot about the ACK. I agree that should be sufficient to test the connection.