#186 - Add FunctionParameter model and reduce schema parsing

[scott-taubman]

Closes #186

This switches the Function model to having its parameter definitions stored in a new model FunctionParameter, rather than through the pre-generated schema. The reasons for doing this are:

• It makes Function and Workflow consistent in their parameter handling
• It makes interacting with the Function parameters (find parameters of type X) much easier, since wasn't any tooling for parsing and interacting with the pydantic generated schema.
• It makes us must less tied to the pydantic library and its schema format, since we have the parameter data in a format that we can easily feed into any library of our choosing.

The main changes that are happening here:

• A new FunctionParameter model now exists. It and WorkflowParameter share a common base, so those two models and the base model now live in core/models/parameter.py.
• The builder has been updated to create (and delete) FunctionParameter instances rather than generating a pydantic schema.
• The TaskParameterForm now uses the info from the FunctionParameter instances to construct the form, rather than relying on the schema.
• There is now a core/utils/parameter.py (not to be confused with the now deleted parameters.py) that is the home of all of the logic that deals with pydantic. Generating the schema and validating parameters against that schema all happen here. This file is also now the home of the single source of parameter type definitions. The various places that had defined their own parameter types now just import it from here.

Other related changes:

• The code that was in core/utils/serialization.py was no longer needed after these changes so that file is now gone. A much simpler helper method that just finds the json parameters from the database is included in core/utils/parameter.py and used internally by t he validated_parameters function there.
• Many of the unit tests needed to be update to replace the function schema in various fixtures with FunctionParameter instances.

Test Instructions

• Some new unit tests were written to confirm that the validation on WorkflowRun and the FunctionParameter removal during the build process work as expected.
• Make sure that package builds still work, functions are still taskable, and field validation in the UI still works. The behavior should be the same as before in all cases.

[scott-taubman]

I'm not entirely clear on why this is a separate thing from PARAMETER_TYPE_CHOICES, but that's how it was before and I decided to just keep it (though I renamed it for consistency).

[scott-taubman]

This got bumped outside of the try block since:

• The exceptions being handled didn't seem like they could be raised by the lines here.
• The linter was rightfully complaining later on that technically functions could be unset.

[scott-taubman]

I realized this deactivate_removed_functions call was in the wrong spot before, so I fixed that here.

[scott-taubman]

I know one of the complaints has been that there are multiple mappings to go update when we add a parameter type. I don't know that we can get it down to only 1 place, since in a case like this it's a mapping that's hyper specific to the TaskParameterForm. I think having the constants defined at least makes it a little less error prone.

[kvig]

I was testing and accidentally deleted part of a function and left the parameters section. The package.yaml ended up with two parameter sections:

      # (required) Parameters that the function takes
      parameters:
        - name: a
          type: integer
          default: 1
          required: true
        - name: b
          type: integer
          default: 1
          required: true

      # (required) Parameters that the function takes
      parameters: []

I don't know if this was a feature before the refactor, but if we can catch this misconfiguration that'd be good thing. I'd error on multiple parameter definitions.

[scott-taubman]

The package.yaml ended up with two parameter sections...if we can catch this misconfiguration that'd be good thing

We unfortunately cannot detect this particular error, since the library we're using (pyyaml) merges duplicate keys rather than throwing an error. This goes against the yaml spec, but it seems like they've never reached consensus on how to fix it. See discussions here and here.