Bad states with --seed

[dbluhm]

When using the --seed cli argument, ACA-Py makes the assumption that the generated DID is published on the connected network. This is all well and good; the process of getting your DID onto a mainnet can be complicated so leaving that process out of band and then giving ACA-Py a mechanism to bootstrap into a wallet with that DID that has been meticulously prepared is helpful. However, it can leave the door open to entering some invalid states in many circumstances.

One example:

• I start up ACA-Py with a seed.
• My DID is NOT actually published to the connected network but I don't realize this.
• I attempt to publish a schema.
• The schema is generated and stored in the wallet.
• ACA-Py attempts to publish the schema. The transaction fails.
• I now understand that my DID is not published. I take steps to mitigate.
• My DID is now published.
• I attempt to publish the same schema.
• The schema already exists in the wallet and I can't reuse the same name and version so the request fails.

We could implement workarounds for clearing out schemas that didn't actually make it to the ledger. I think it would be more useful to add guards that ensure ACA-Py's DID is public when it thinks it is before committing bad state to its wallet.

At a minimum, I think we should check if the DID generated from the seed is actually present on the network on start up and shut down if it isn't.

[jamshale]

The startup function where this provisioning/seed logic takes place is very convoluted. I'll be trying to refactor it in another task.

Definitely think there's improvements to be made here. Possibly a sequence diagram would be helpful as well. The amount of configurations and different paths make this very confusing. There's seed, replace-public-did, auto-provision, recreate, local-did, etc... that all can affect each other and the wallet state on startup.