feat: suppress redundant IPEX initiator notifications

[kentbull]

IPEX operation initiators do not need notifications of events they create as it is redundant. Suppressing notifications for IPEX operations like this, for initiators, is similar to how Multiplexor in KERIpy suppresses notifications for multisig operation initiators.

https://github.com/WebOfTrust/signify-ts/pull/399/changes can be moved from draft to PR once this is merged.

[codecov]

Codecov Report

❌ Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 87.76%. Comparing base (8a1b9e2) to head (63798f2).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/keria/app/ipexing.py	90.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #445   +/-   ##
=======================================
  Coverage   87.75%   87.76%           
=======================================
  Files          26       26           
  Lines        5825     5834    +9     
=======================================
+ Hits         5112     5120    +8     
- Misses        713      714    +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[iFergal]

If we want to do this, we should probably just avoid calling handle so it will apply to all exns?

There is a nice advantage of keeping the extra notification that we are using in Veridian Wallet which I think is worth considering though.

In a threshold multi-sig, any members who don't sign get a notification that the exn was fully signed automatically, which is useful for UX.

[kentbull]

If we want to do this, we should probably just avoid calling handle so it will apply to all exns?

This would require subclassing KERIpy's Exchanger since that is what calls .handle() on all registered message handlers. I have not yet fully thought through whether this makes sense for all exns, yet in abstract it seems okay. It doesn't seem the initiator of a challenge response, OOBI exn resolution request, IPEX, or multisig operation needs to be notified of their own operation. Maybe we could just avoid calling handle like you say.

There is a nice advantage of keeping the extra notification that we are using in Veridian Wallet which I think is worth considering though.
In a threshold multi-sig, any members who don't sign get a notification that the exn was fully signed automatically, which is useful for UX.

Does this imply that you are having a non-signer multisig member initiate an event?

[iFergal]

Does this imply that you are having a non-signer multisig member initiate an event?

No. For example, for a 2 of 3 multi-sig that receives a presentation request: if Alice responds with a presentation, and Bob also signs, Carol will get a notification of the presentation which indicates that enough signatures were collected and that she doesn't need to sign.