[Backend] JSON PATCH Endpoint for Datasets/Saas Configs

[pattisdr]

Describe the solution you'd like

This is to support a UI where we want to allow more targeted edits to specific fields. This is not necessary for a UI where we are uploading an entire yaml or updating an existing yaml.

For making edits to a datasetconfig or a saasconfig, your only option currently is to edit a very deeply nested JSON body and PATCH the whole thing back to Fidesops.

Add a new endpoint(s) PATCH /dataset/{fides_key} that supports incremental edits to a dataset with request bodies inspired by JSON Patch format, with slight adjustments. The frontend should be able make requests saying to add/remove/replace a collection/field/reference/identity without having to know the index of its location or whether a key exists already, the backend will take care of that. The frontend request body should be as simple as possible, and the backend is responsible for re-formatting in the appropriate way.

The backend should be responsible for taking the frontend request, formatting them into appropriate index-based patch operations, and applying the patch on the dataset or saas config using python-json-patch. Since the backend needs to make edits anyway, we may just avoid python-json-patch and just roll our own solution. It should fail in an all or nothing way. If all the operations can't be completed, none of it should be persisted to the database. It should support an unlimited number of patch operations, one operation, ten operations, etc.

Unlike JSON Patch format, don't specify indices in path.

[
  { "op": "replace", "path": "/baz", "value": "boo" },
  { "op": "add", "path": "/hello", "value": ["world"] },
  { "op": "remove", "path": "/foo" }
]

Describe alternatives you've considered, if any

Early design review had the frontend be entirely responsible for building properly formatted JSON Patch operations. To lighten the FE load, we are looking into moving more of the logic to the backend. If a collection key doesn't yet exist on the dataset, the backend should add it for example, without the FE having to specify that it needs to be added.

Additional context

Output of ticket:

• Determine what information for Saas configs will need to be incrementally edited at this time. Saas connectors differ from database connectors in that their configuration is stored in two locations instead of one. References for example, are stored on the saas config instead of the dataset for a saas connector, while they are stored on the dataset for a database connector. If very minimal edits are needed to the saas config, we could potentially have one endpoint that figures out if the information should be persisted to the saas config or the dataset config.
• Determine request body first. - Specify frontend request bodies for adding/updating/deleting a collection/field/nested field/reference/identity. Make the request body as simple as possible. For example, the FE could specify we want to add a reference, but the backend figures out that it needs to go under fidesops_meta.
• Determine if we should use python-json-patch or roll our own solution.
• Add the new api endpoint(s) to support these edits. - figure out if saas configs and dataset configs should be updated through the same endpoint.

[pattisdr]

Note: Reference checking won't be added here. If a reference is added, for now, we'll just add it, we won't validate that it exists. This is in line with our current practices. Reference checking can be added as a follow-up.