feat(did-comm): add trust ping protocol

[nickreynolds]

What issue is this PR fixing

closes #1079

What is being changed

A clear description of what this PR brings.

Quality

Check all that apply:

• I want these changes to be integrated
• I successfully ran yarn, yarn build, yarn test, yarn test:browser locally.
• I allow my PR to be updated by the reviewers (to speed up the review process).
• I added unit tests.
• I added integration tests.
• I did not add automated tests because _________, and I am aware that a PR without tests will likely get rejected.

Details

If applicable, add screen captures, error messages or stack traces to help explain your problem.

[codecov]

Codecov Report

Merging #1080 (69ca244) into next (125bf42) will decrease coverage by 0.50%.
The diff coverage is 77.27%.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #1080      +/-   ##
==========================================
- Coverage   80.25%   79.74%   -0.51%     
==========================================
  Files         118      132      +14     
  Lines        4056     4739     +683     
  Branches      875     1016     +141     
==========================================
+ Hits         3255     3779     +524     
- Misses        798      960     +162     
+ Partials        3        0       -3     

[mirceanis]

Looks good, kudos for the thorough testing!

It's a straight forward approach, using the message handler chain for this, and consistent with the existing codebase.
I'm not sure if this is a problem for this protocol, but this can be triggered by any message that looks like a trust ping, even if it doesn't come through didcomm.

Another possible approach for protocol implementations would be to create protocol handlers as agent plugins that react based on event listeners.
Maybe for future protocols we can also explore this option but we need to figure out how to forward events for agents that use @veramo/remote-client

That being said, now with a new message handler supported, we should also update our default CLI config file.

[nickreynolds]

It's a straight forward approach, using the message handler chain for this, and consistent with the existing codebase. I'm not sure if this is a problem for this protocol, but this can be triggered by any message that looks like a trust ping, even if it doesn't come through didcomm.

Another possible approach for protocol implementations would be to create protocol handlers as agent plugins that react based on event listeners.

@mirceanis

Yeah, it being able to be triggered by "non didcomm messages" was intentional. It at least makes testing a bit easier since it can be separated from didcomm's own message handler. I don't feel strongly though, but it seems fine to do it this way?

I was considering using the event listener system as well, but it seemed to work well with the message handler flow. If we decide that other "didcomm protocols" should use the event system, I can refactor this one at that time.

Made the small changes you requested

[mirceanis]

Looks great!

Yeah, we can refactor to event system later, if needed.

Please also consider adding this new handler to the default CLI config