Bug: Idempotency in mediator invitation flag

[dbluhm]

ACA-Py has the argument --mediator-invitation which is used to automate the process of connecting to a mediator, coordinating mediation, and setting that mediator as the default for future connections. The intent of this flag was to be used once on first startup; however, accounting for this in typical deployment scenarios is not trivial where no facilities exist for changing the startup command after the first run.

I think we could solve this a number of different ways but here are my suggestions:

• Create a new argument for the provision command that takes the mediator invitation and stores it. Then, on startup, ACA-Py will see this stored mediator invitation and use it to establish mediation (following the already established behavior of the --mediator-invitation argument on the start command, just not using the argument). Provision provides the correct setup semantics for this interaction but ACA-Py cannot engage in a DIDComm protocol until it is fully started, hence the actual mediation establishment only happening after startup.
• Make the --mediator-invitation argument idempotent. This might be accomplished by storing the invitation passed in the argument and for each startup after where the invitation has not changed, do not attempt to establish a connection, coordinate mediation, or reset the default mediator.

My personal preference is for the first option since this operation aligns with the intent of the provision command. However, we should consult with Matteo to see which option is more conducive to real world deployments.

[burdettadam]

Invitations are stored with connection records? We could also check if the connection has been created with the same invitation as the one provided in the configuration and handle it correctly if it's been used already.

[dbluhm]

I don't believe the stored invitations are searchable by any value other than connection ID which would mean we'd either have to add tags to invitation records that make the invitation searchable or iterate through all connections and check the attached invitation. In the first scenario, the tag would have to be some value from within the invitation or the whole invitation URL itself. This is feasible but I lean towards just having one record type for last seen mediator invitation just because it's really simple.