Add basic plugin support

[mrmr1993]

This PR adds basic plugin support, using the Dynlink module to dynamically load modules passed on the command line. Currently, the interface only exposes a reference to Coda_lib.t, and this PR adds no hooks that a plugin could attach to.

We want this to allow node operators to manage exchange rates, without our prescribing a specific system. This will allow us to expose simple hooks that operators can use to manage rates in any way that they see fit.

It may also make sense to move some other things to be plugins, or expose plugin interfaces for them. For example,

• prometheus metrics
  • many (/most?) operators will not use these
• trust system
  • nodes may want stricter/less strict rules than the default, or special-casing for some nodes
• SNARK proving
  • this would allow swapping in a custom/GPU implementation without needing to recompile a custom coda binary

To test:

dune build src/lib/coda_plugins/examples/do_nothing/plugin_do_nothing.cmxs
make build
_build/default/src/app/cli/src/coda.exe daemon -seed -demo -load-plugin _build/default/src/lib/coda_plugins/examples/do_nothing/plugin_do_nothing.cmxs

Lines similar to these should appear in the log:

2020-07-27 15:19:25 UTC [Info] Initializing plugins
2020-07-27 15:19:25 UTC [Info] Initializing plugin from $path
        path: "_build/default/src/lib/coda_plugins/examples/do_nothing/plugin_do_nothing.cmxs"
2020-07-27 15:19:25 UTC [Info] Hi from do-nothing plugin!
2020-07-27 15:19:25 UTC [Info] Plugin successfully loaded from $path

Checklist:

• Document code purpose, how to use it
  • Mention expected invariants, implicit constraints
• Tests were added for the new behavior
  • Document test purpose, significance of failures
  • Test names should reflect their purpose
• All tests pass (CI will check this if you didn't)
• Serialized types are in stable-versioned modules
• Does this close issues? List them:

[psteckler]

After the plugins are loaded, regardless of error status, get_coda_lib always raises?

Should the exception be named Done_initializing plugins?

Should an error be fatal?

[mrmr1993]

This error can also happen before init if a plugin gets linked into the main coda binary by mistake. Since linking order can affect this (and is hell to debug) I took the stance that it should always be an error if a plugin is linked into the coda binary itself.

I've updated this to make these errors fatal.

[psteckler]

Should plugins be required to support an interface of some kind, perhaps indicating a name, author, description, that could be logged (or result in failure)?

[mrmr1993]

Should plugins be required to support an interface of some kind

For now, I think we should treat this as an avenue for testing fees in tokens without writing a production-ready exchange rate mechanism. I think there should probably be a full RFC for how the API and system should work before we promote this as a feature or recommend that anyone uses it -- especially since it directly exposes the internals at the moment.

It might be better not to expose it in released binaries yet. Do you think this should be behind a compile-time flag for now?

[psteckler]

Do you think this should be behind a compile-time flag

That sounds like a good idea.

[psteckler]

I think you can use ifdef plugins, then you only have to define it in the profiles where it's needed.

[mrmr1993]

I get an error from optcomp, where it asks for [%%undef plugins] in the config :/