(re)Define API between Scholarsphere and MetadataListener

[awead]

There is an implicit API between MDL and SS that is exposed when SS sends MetadataListener::Job that MDL must run. SS is supposed to include all the information that MDL needs to run the job, i.e. the endpoint, API keys, reports to run, and other things. There could be additional information, either on a per-report basis, or not, that SS might need to provide. If the process changes on either side, the information exchange ought to be robust enough that the parameters can remain the same, and when additional reports are added, such as more derivatives or other features, those parameters can be added without affecting the operation of the others.

TODO

• Refactor reports to include or inherit MetadataListener::Report::Base Refactor reports to include or inherit MetadataListener::Report::Base #54
• Make the derivatives store configurable Make the derivatives store configurable #52
• Make a separate id parameter for Job Make a separate id parameter for Job #32
• Allow configuration options on a per-report basis Allow configuration options on a per-report basis #53