Propose new plugin interface

[dbluhm]

I'd like to propose a slightly different mechanism for loading protocol handlers as well as other features. Rather than specifically looking for message types inside of a loaded module, I propose that we attempt to load and execute an asynchronous setup method, with the context passed as the first argument. This would allow side loaded modules to not only add protocol handlers but also potentially define new ledgers, admin servers, admin server routes, etc. without having to fork the ACA-Py code base. The changes I've included here are mostly just a proof of concept of what this might look like and other changes are likely necessary to fully support side loading something like a ledger.

More than open to thoughts and feedback, why this approach is a bad idea, ideas for a better approach etc.

[codecov-io]

Codecov Report

Merging #248 into master will decrease coverage by 0.03%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master     #248      +/-   ##
==========================================
- Coverage   74.53%   74.49%   -0.04%     
==========================================
  Files         219      219              
  Lines       10162    10171       +9     
==========================================
+ Hits         7574     7577       +3     
- Misses       2588     2594       +6

[andrewwhitehead]

I feel like this should replace --protocol, not complement it

[dbluhm]

I feel like this should replace --protocol, not complement it

That sounds reasonable to me; my thoughts with leaving it in was not breaking compatibility for anyone currently using the --protocol argument.

[andrewwhitehead]

@dbluhm I think we'll add this change as part of some other refactoring we're doing at the moment, but I'm looking at loading all the plugin modules into the ProtocolRegistry early on, then calling the setup method for each one (if defined) when the context is initialized. Admin routes would be loaded based on the same module registry.