Add schema modeling guidance for enum values as lower_snake_case

[jack-berg]

Realized we don't consistently model enum value types when reviewing this spec PR.

Ideally, we would have case insensitive enums, but JSON schema doesn't support those without resorting to using regex patterns.

Choosing snake case because we already have modeling guidance saying that property names are snake case.

[MrAlias]

Should the values be case-insensitive? Do we want to distinguish between info and INFO?

[jack-berg]

JSON schema doesn't support case insensitive enum values @MrAlias. I would be in favor of case insensitivity if we could express it reasonably

[jack-berg]

JSON schema doesn't support case insensitive enum values @MrAlias. I would be in favor of case insensitivity if we could express it reasonably

[MrAlias]

In that case, can we use uppercase snake case to match existing definitions like the log severity?

[jack-berg]

See #449.

Notably:

Advantage of upper snake case is that enums stick out very clearly.
Disadvantage is that more types are impacted:

• lower_snake_case impacts 2 types, both of which are experimental
• UPPER_SNAKE_CASE impacts 7 types, one of which is experimental, 6 of which are on stack to stabilize

[codeboten]

i prefer the lower case to upper case option

[codeboten]

If you can address the conflicts and update the description for the enum, i think we can move this forward

[MrAlias]

I don't have a strong preference on casing. Just more used to the upper-case.