Better handling of enums #29
Description
The current implementation, based on CEL-Go, implicitly converts every enum-value to a raw int type. "Raw int type" means, that it loses contextual information that the int value is actually the ordinal of an enum-type and therefore it is currently only possible to compare enum-type-properties against an int or the fully-qualified enum. For example these CEL expressions work: someobject.enum_field == 123 and someobject.enum_field == org.projectnessie.cel.demo.EnumType.ENUM_VALUE , but an expression like someobject.enum_field == 'ENUM_VALUE' does not work, because if would compare an int with a string.
Making enum-types first-class citizens in the type system, i.e. add an org.projectnessie.cel.common.types.EnumT, would allow comparing against a string and even iterate over its values.
The implementation of EnumT is somewhat similar to ObjectT. It returns the message (type) name of the enum as its type name.
It is important to maintain the current backward/forward compatibility with enum values at least for protobuf (with the ProtoTypeRegistry) - i.e. allow arbitrary enum ordnial values that are not defined or are negative.
For Java (with the JacksonRegistry) it probably does not make a lot of sense to allow querying enum-type attributes - i.e. JavaBean-getters defined in the Java enum. In fact, what such getters returns actually depends on the current enum implementation, which is not a portable thing.
With this change, the conformance tests for enums, which are currently skipped, should be enabled.
See also:
/cc @nastra