Enable no-transport mode as startup parameter

[PatStLouis]

This PR adds a --no-transport startup parameter for making the agent start without requiring the --enpoint, --inbound-transport and --outbound-transport to be set.

The idea was shared during an aca-pug meeting and there was no objection. This can greatly simplify deployment for controllers that do no require didcomm messaging.

Currently it just overrides what is required for startup.

@dbluhm @swcurran @ianco

[dbluhm]

Like I mentioned in the ACA-PUG call, I like where this is going. Having the ability to use ACA-Py's credential, DID Resolution, and other capabilities without necessarily using the DIDComm capabilities is really interesting.

I think you're already headed in this direction but if no transport is enabled, it is likely not necessary to register any of the protocols.

[dbluhm]

Integration tests are consistently failing. The question is whether that's a result of the changes in this PR or not.

 Failing scenarios:
  features/0586-sign-transaction.feature:124  endorse a schema and cred def transaction, write to the ledger, issue and revoke a credential, manually invoking each endorsement endpoint -- @4.1 
  features/0586-sign-transaction.feature:234  endorse a schema and cred def transaction, write to the ledger, issue and revoke a credential, with auto endorsing workflow -- @1.1 
  features/0586-sign-transaction.feature:245  endorse a schema and cred def transaction, write to the ledger, issue and revoke a credential, with auto endorsing workflow -- @3.1 

It doesn't seem like these changes should impact these scenarios... @jamshale any insights?

[jamshale]

I noticed this but have not dug into it. I'm not sure how this is effecting endorsement but it must be as integration tests are passing on the nightly runs and for other pr's. I can try and see if I can figure anything out.

[PatStLouis]

I will have a look, no additional tests were added and no changes are expected if the flag is not added. Maybe there's a bad condition check somewhere.

[jamshale]

I haven't tried to debug it yet but these failing tests are trying to use the /ledger/register-nym endpoint via the register_did method in demo/runners/support/agent.py and getting a 400 error.

[PatStLouis]

@dbluhm @jamshale I think I found the error, copy paste mistake. I was registering the ledger as a package and not a plugin. Lets see how the test go now

[PatStLouis]

Tests passed, updating the branch

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[PatStLouis]

@dbluhm @jamshale branch updated, all tests are passing. Let me know if you need anything else!

[ff137]

@jamshale @dbluhm
Just a heads up, this change causes the LedgerAPI to be dropped from the OpenAPI spec that gets generated with bash scripts/generate-open-api-spec, since it uses --no-ledger in its startup args.

Just thought I'd mention. It just means if repo's openapi spec is regenerated, it won't include ledger API. But it should still appear in the swagger.json for an agent that does have ledger configured.

A simple fix is to just revert this line's change. Otherwise, seems like genesis-file / transactions needs to be configured in open-api gen bash script. Seems overkill to do that

[PatStLouis]

I can revert this, it's not crucial to what I was trying to achieve here. I'll submit a PR, thanks for flagging this!

[ff137]

Cool! Picked it up when generating openapi client off nightly build. Thanks! 👍