refactor: remove connection protocol

[dbluhm]

This PR Removes the deprecated connections protocol.

In addition to the message handlers and routes, this also means:

• CLI flags relating to connections protocol removed.
• References to specific messages in base connection manager were removed; there will need to be some working around this in the plugin to continue to support the protocol but I think it's good and necessary to at least rip it out for now here.
• Introduction protocol used to use Connections invitations. I did a very rough-and-ready conversion to OOB invites.
• Connections management routes (e.g. querying connections) were moved to aries_cloudagent.connections.routes (from aries_cloudagent.protocols.connections.v1_0.routes).

I am expecting this to not be fully functional yet so opening as a draft for now.

[PatStLouis]

@dbluhm it was mentioned on the call this was moved to a plugin. Is the code to enable using that plugin included in this pr?

[swcurran]

It’s in the plugin repo: openwallet-foundation/acapy-plugins#925

[PatStLouis]

@swcurran thank you, I was referring towards the "code required to make this plugin work" which was highlighted in the meeting.

The functionality lost/broken features outlined here, will this require code from within the aca-py code base or it can all be managed in the external plugin?

[swcurran]

Doh…sorry about that. Good point. And per my comment in the meeting — is it viable to simply document how to use the plugin? I suppose not being able to use the artifacts directly (e.g., having to change the Python code) might be a bit too painful.

[dbluhm]

With the most recent updates on this branch and to the corresponding plugin, I have successfully completed a connection using the plugged in connection protocol. There are some failing tests I will address but I will go ahead and mark this as ready for review.

[sonarcloud]

Quality Gate failed

Failed conditions
52.8% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[jamshale]

This looks great! I think this deprecation support path is really going to help manage complexity.

I'm just wondering if maybe a scenario test that installs the plugin and creates a v1 connection might be a good idea.

I don't see any reason not to approve this. We'll need good docs for when it gets released. Guaranteed people are going to upgrade without realizing this change has happened.

[swcurran]

Cool. Let’s include in our discussion tomorrow the version number if we remove this. 1.1.0?

Should the SonarCloud analysis be addressed before merging?

[dbluhm]

I'm just wondering if maybe a scenario test that installs the plugin and creates a v1 connection might be a good idea.

We can do that though this is basically what's happening in the integration test of the plugin itself. So I'm not sure how valuable it is for it to be tested in both places.

We'll need good docs for when it gets released.

Indeed, I have not adequately addressed this need yet.

Should the SonarCloud analysis be addressed before merging?

I am not too concerned personally. The most complaints are coming from code that was just moved but detected as new in the connection routes (moved from the protocols.connections.routes to connections.routes).

[sonarcloud]

Quality Gate failed

Failed conditions
37 Security Hotspots
4.7% Duplication on New Code (required ≤ 3%)
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint