Improve settings validation and type handling

[naz]

The Problem

It is unclear what values can be set for each key in the settings object. This caused issues like #10576 and #10580

Current state

At the moment we don't have clear schema definition for all the values that can be stored in settings. There is a validation present on model layer, but it doesn't contain validations for all fields. We are not consistent with how boolean values are stored in the database.

Future improvements

We need to review uses of following data types/values that might cause the most of problems:

• booleans - we currently store "true", "false", "0" and "1" in the DB, but should be storing only "true"/"false"
• null/empty/undefined,
• dates/timestamps

List of issues should be tackled for booleas:

• migration which corrects "0" to "false" and "1" to "true"
• a proper db input normalizer on model layer. this would handle e.g. stringification of booleans true/false into "true"/"false" to be stored in the db
• API validator which ensures sending "false" or "0" to settings is converted into boolean bot be used in further layers
• adapt importer to not forward "0" to model layer
• remove force_i18n in api input serializer

[kirrg001]

One addition: Exports might have "0" or "1". We have to ensure that these imports won't fail again 👍

[kirrg001]

Another addition: force_i18n is deprecated. We won't serve it. We should not skip this value on API layer.

[naz]

We don't have any specific handling for null/undefined values in keys atm. When the value is not present for a key, this check in Settings model prevents it from being set to undefined:

if (item.hasOwnProperty('value')) {
    setting.set('value', item.value);
}

Ideally objects without value provided woulld be filtered out in API validation layer.

As for null value, it is processed as expecte and stored as NULL in the db. There is a minor inconsistency where we sometimest store empty string "" to identify emtpy value but also allow it to be set to null (for example value for icon key).

Regarding date/timestamp fields, the only values we store are for next_update_check which comes from the request made to https://updates.ghost.org. We don't have any validation around this value but seems improbable that anything will break. Unless we would want to be extra cautious, don't think we need to do anything about it.

[kirrg001]

As for null value, it is processed as expecte and stored as NULL in the db. There is a minor inconsistency where we sometimest store empty string "" to identify emtpy value but also allow it to be set to null (for example value for icon key).

This needs some more context. Worth raising a separate issue with your findings.