Officially state that enum-like types treat 0 as unspecified/invalid

[gilles-peskine-arm]

A minor design decision in the PSA Crypto API is that in enum-like types, the value 0 is reserved to mean “unspecified or invalid”, unless there is a good reason not to. (An example of a good reason not to is psa_status_t, where 0 means success.) This is explicitly specified for some types (e.g. psa_key_type_t, psa_algorithm_t) but not for others (e.g. psa_ecc_family_t, psa_dh_family_t).

We should specify this for all the enum-like types, and add a note somewhere in the API conventions section.

For psa_key_derivation_step_t, the specification does not define numerical values (because these values do not typically end up in persistent storage). However I think the specification should still recommend to leave 0 as undefined. (Making this compulsory could break existing compliant implementations.)

(Prompted by Mbed-TLS/mbedtls#7533 (comment))

[athoelke]

This is quite straight-forward for the ECC and DH-group families, and as a general convention.

In contrast, psa_key_lifetime_t does define a meaning for 0, which is 'default volatile key location. However, this is usefully exploited as the default lifetime for a freshly initialized key attribute object. Many of the other value types (algorithms, key types, etc.) do not have a useful 'default' value - so reserving 0` to be invalid is valuable in detecting missing application code.