Integrate various sources of API truth

[atruskie]

Our API currently learns about models and how they should be serialized via filter settings.

Given we can now generate documentation for the API (#479) in the OpenApi format, we need somewhere to generate or specify JSON schema definitions for that specification.

Currently in https://github.com/QutEcoacoustics/baw-server/pull/479/files/219e497000ca04ea71007ae28f60e9bb8a0e1455#diff-091778d5c1679dbdc51b6db971f68d22R107-R122 we just specify the schema as a class property on the model.

However, we know have three sources of truth for API models:

• filter settings
• schema
• and allowed strong parameters in updates to controllers

I think that all three sources should be integrated so that there is one source of truth (filter_settings) and the other two sources should be generated from the first.

[Allcharles]

This also relates to something that may be a separate issue.

Baw-server will generate and pass forms for editing models. Currently, the expected json outputs are visible in workbench-client (https://github.com/QutEcoacoustics/workbench-client/blob/master/src/app/component/projects/project.schema.json), however the end goal is for these files to be extracted to the baw-server and retrieved whenever a form is displayed on the website. The generation of this file should also be created from the filter_settings.

[atruskie]

Baw-server will generate and pass forms for editing models.

Well it won't generate forms. /new will return an empty object that will be templated (a little redundant in a SPA scenario). I also intend for the responses to return the json schemas for the models, which we can use as the basis of automatic form generation.

So the new response would be roughly:

{
  "meta": {
    "schema": { 
       // schema here
   },
  "data": {
      // emtpy model here
   }
}