Feat/public did endpoints for agents behind mediators

[cjhowland]

This PR supports publishing endpoint information with routing keys in accordance with the did:sov specification. Routing keys are retrieved from mediation_id if specified, or else a default mediator. If no mediated connection is present, routingKeys defaults to an empty array.

This PR allows for publishing DIDs with routing keys; PR #1863 allows for resolving DIDs with routing keys.

[dbluhm]

Thank you for the thorough tests! I have just one minor change request.

[dbluhm]

To further comment on the necessity of this PR, without this, an ACA-Py instance configured to operate behind a mediator is currently unable to publish accurate endpoint information for forming DIDComm connections through its public DID.

[codecov-commenter]

Codecov Report

Merging #1899 (e1e8d77) into main (2a0e088) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1899   +/-   ##
=======================================
  Coverage   93.67%   93.68%           
=======================================
  Files         539      539           
  Lines       34145    34162   +17     
=======================================
+ Hits        31984    32003   +19     
+ Misses       2161     2159    -2     

[dbluhm]

The SonarCloud analysis is new. It's complaining about test values. @cjhowland we could probably appease it by just changing the example endpoint to something like https://example.com.

[WadeBarnes]

The SonarCloud analysis is new. It's complaining about test values. @cjhowland we could probably appease it by just changing the example endpoint to something like https://example.com.

Yes, it's new. It just got added to some of the Indy and Aries projects today. It's not a required check yet, so it won't block merging.

[dbluhm]

Should/Can we configure it to ignore tests? I suppose if we leave it as a not required check, maybe it's not a problem but "fixing" the code duplication warnings for the tests would be inappropriate, IMO. Maybe I just have an aversion to seeing red X's on PRs that I'm approving 🙂

[WadeBarnes]

Should/Can we configure it to ignore tests? I suppose if we leave it as a not required check, maybe it's not a problem but "fixing" the code duplication warnings for the tests would be inappropriate, IMO. Maybe I just have an aversion to seeing red X's on PRs that I'm approving 🙂

Yes, the settings can be adjusted by adding a config file. Example config file; https://github.com/hyperledger/blockchain-explorer/blob/8c85d2a6b0f3b7af88c80ce2fd3f252138d09343/.sonarcloud.properties

[dbluhm]

Char is OOTO so I'll take a look at test failures today.

[WadeBarnes]

More suggestions here; #1896 (comment)

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

No Coverage information
10.5% Duplication

[dbluhm]

LGTM!

[ianco]

Please see PR bcgov/von-network#233