[AATH] Incorrect state reported by AATH Connection Handler when it should have completed

[gmulhearn]

The AATH results for the ./manage runset ariesvcx-acapy runset is choking due to the aries-vcx connection handler reporting that it is still in the "request" state, after it has sent a response and received a trusttping... This tanks the results:

0 features passed, 6 failed, 9 skipped
2 scenarios passed, 32 failed, 126 skipped
105 steps passed, 32 failed, 1246 skipped, 0 undefined
Took 26m20.208s

compared to ./manage runset acapy-ariesvcx which does ok:

3 features passed, 3 failed, 9 skipped
22 scenarios passed, 12 failed, 126 skipped
251 steps passed, 12 failed, 1120 skipped, 0 undefined
Took 13m19.274s

We need to fix the connection state that VCX reports when it is the Connection 0160 Inviter/Responder and receives a trustping

[gmulhearn]

acapy (and agents other than vcx) are sending an trust ping message after receiving the connection response from VCX. then the VCX backchannel does not handle this trustping, it silently ignores it; leaving VCX is the state of "request" (when really it should be in atleast the "response" state).

in the case of ariesvcx-ariesvcx, it does NOT send a trustping, it sends an ACK, which the VCX backchannel CAN handle and will bump the connection state from request->complete. So the problem of incorrect state does not manifest.

Perhaps just adding support for Trustping is an easier fix here.

[swcurran]

Some background. The RFC 0160 Connections protocol completion was left without a confirmation of the connection (bad design), and the “recommended” solution was to do a trust ping immediately after setup to confirm the connection. As such, that is what ACA-Py and other frameworks have done, so yes, implementing Trust Ping is the easiest fix.

The protocol issue was “fixed” in RFC 0023 DID Exchange, but alas, 0160 was already in stone. A pain.