feat(shared-data, api): remove 'default' from all '..ByVolume' properties

[sanni-t]

Modifies the schema from ticket AUTH-832

Overview

After some discussion with product & hardware, we have decided to remove the 'default' keys from all '..ByVolume' properties in liquid classes since they were causing confusion and were trying to add a flexibility that would not be realistically needed.

The other change in this PR is changing the format of the schema for byVolume properties, turning them from a mapping of volume to value, to an array of 2-tuples containing the volume and corresponding value, removing the reliance on schema property name regex to ensure the volume is a valid float.

Test Plan and Hands on Testing

Added test to validate fixtures and definitions against schema

Changelog

• removed 'default' entries from liquid class schema, definitions and fixtures, as well as from the PAPI liquid classes interface.
• changed byVolume properties in schema from object to array of 2 element arrays

Review requests

Any place I've forgotten to update?

Risk assessment

None.

[ddcc4]

Hey, in liquid_class_definition.py, there were a bunch of things that were defined as dict[str, ...], I assume because we had to support default as a key in the dictionary.

With this change, can those definitions be tightened up to dict[float, ...] now? Or do they have to be dict[str, ...] because you want to use strings in the JSON dictionaries?

[jbleon95]

Hey, in liquid_class_definition.py, there were a bunch of things that were defined as dict[str, ...], I assume because we had to support default as a key in the dictionary.

With this change, can those definitions be tightened up to dict[float, ...] now? Or do they have to be dict[str, ...] because you want to use strings in the JSON dictionaries?

The latter, they should stay dict[str, ...] to represent the JSON keys

[ddcc4]

Cool. So if I understand this properly:

You have to use d+ as the validator for the key because the keys are strings, and the most you can do to validate strings is to write a regex for it? But you can use #/definitions/positiveNumber as the validator for the values because those are numbers?

Are the keys limited to strictly d+? E.g., is 1.5 a valid value for the key, and would that match d+? (Would the decimal point match d+?)

[ddcc4]

Is this autogenerated? Do you have to specify integers and numbers separately like this?

[ddcc4]

FYI, I think you can just say console.log(a, b, c) instead of manually stringifying and concatenating them with +. In some environments (like the browser inspector or colorized consoles), it produces prettier output because the system can interpret each argument individually.

Similarly, if you don't need to stringify() the validationErrors, see if you can just log it as-is, again so that we can get pretty-printing in the console.