Correct ranges and enums for various preference values

[confluence]

Fixes #8.

This PR corrects several restrictions on preference values which are out of sync with the frontend and cause unexpected behaviour because of schema validation errors.

These changes mostly affect the frontend, so I will describe the details in the related frontend issue.

I have removed the types from preferences which have values restricted to enums -- per the JSON schema docs, including them is considered bad practice, as the enum already implicitly determines the type(s).

Some constraints have been relaxed, so that limitations in the frontend input GUI don't restrict what valid values can be entered, and so that we don't make it unnecessarily difficult to change these input selections.

Companion PRs in the backend, frontend, and controller.

[loveluthien]

Do we need to consider the case that users modify the value directly in preferences.json? If yes, users giving any unvalidated value will cause preferences to be reset. I guess we need to handle the incorrect value in preferences.json to be able to upgrade those values.

[confluence]

@loveluthien only the individual preferences which are invalid will be reset. I think this is to be expected if users manually edit the file and make a mistake; we don't need to add any special handling. In any case, this is an issue for the frontend, not for the schemas (here we only define what the schema should be).

[loveluthien]

Looks good. Feel free to merge if you want to merge tonight, I will update schemas in the frontend in my morning.

[loveluthien]

Please modify this to "minimum": 0 and "maximum": 2

[kswang1029]

minimum 0.1 GB maybe?

[loveluthien]

Only "GB" here.

[loveluthien]

@confluence, ksw found an asynchronous problem when changing the pvPreviewCubeSizeLimit and pvPreviewCubeSizeLimitUnit. Our solution is that store the pvPreviewCubeSizeLimit only in GB in preferences.json, and the frontend UI does the MB conversion (for display only), so pvPreviewCubeSizeLimitUnit in schemas is limited to GB. I also realized that the frontend gives a boundary for pvPreviewCubeSizeLimit between 1e-12 and 2 GB.

[confluence]

@kswang1029 @loveluthien Eliminating the different units simplifies a lot of things -- this is one of the changes I suggested in this refactoring request. If we're doing this now, I suggest that we deprecate pvPreviewCubeSizeLimitUnit entirely (i.e. remove it from the schema and frontend code completely -- old prefs won't break anything because extra prefs are allowed; to clean up we could clear it explicitly in the upgrade code if it exists). I realise now that we can't just ignore it -- we need to convert values saved with other units. This can be done in the upgrade function, and then the unit preference can be cleared. We definitely can't just change the schema to allow GB only -- then the frontend will delete the pref if it has an invalid value, and the limit value will be interpreted as GB when it isn't. I suggest marking this as deprecated in the schema, and not using it anywhere in the frontend except the upgrade function.

Regarding the constraints: pvPreviewCubeSizeLimit is one of the size preferences that I discussed with @veggiesaurus -- the strategy that we agreed on was minimal constraints in the schema (so that they can easily be changed in the frontend input). So I don't want to add a maximum here, but I agree that there should be a minimum (for consistency with other limits) -- the reason there wasn't one previously was the unit complication. This should be the real usable minimum (not a default), even if it's not currently selectable in the GUI, so a fraction of a GB seems like a good choice. Is ± 100M a usable limit? I would suggest 128M or 256M (so 0.125 or 0.25) I see that these are treated as metric, not binary, so actually 0.128 or 0.256.

The current minimum in the frontend should to be changed so that values lower than a sensible minimum aren't allowed: if the unit is GB, 1e-12 is less than a byte! It would be about a byte if the unit were TB, which still seems ridiculous. If you're allowing the user to select input units, the bounds should change with the unit.

[loveluthien]

I will make pvPreviewCubeSizeLimitUnit deprecated.
Do we really need such a small number for the minimum? Is it good to use 128 MB for the minimum, like ksw said?

[confluence]

Do we really need such a small number for the minimum? Is it good to use 128 MB for the minimum, like ksw said?

I am suggesting that we use something like 0.1, as @kswang1029 suggested. I will make more comments in the frontend PR.