Handling NetCDF enums as julia enums

[Alexander-Barth]

This is an alternative way to implement netCDF/HDF5 enum types in NCDatasets as julia enum.

Reference to PR using CategoricalArrays:

• Read netCDF enums as CategoricalArrays #314
• CategoricalVariable feature. CommonDataModel.jl#53

What is works so far:

• read/write Enum variables
• read/write Enum attributes
• Enum with compound variables
• Enum with vlen-arrays
• Enum in ncgen
• [ ] Enum types displayed in show (doing it later with changes in CommonDataModel)

CC:
@lupemba @tiemvanderdeure @evetion

[Alexander-Barth]

Using eval to generate the types (enums or structs) has the drawback that it lead to world age issues when this new datatype is called in a previously defined function and this function for example want to convert the enum into a string:

 ERROR: LoadError: MethodError: no method matching namemap(::Type{NCDatasets.ReconstructedTypes_2437958937.cloud_class_t})         

The applicable method may be too new: running in world age 39256, while current world is 39277.

The solution is to use invokelatest which is ok for NCDatasets to use internally, but not pretty when the users have to call it on their functions.

A drop-in alternative is to define a custom struct for enums (similarity for compound types):

struct NCEnum{T,typename,names,values}
    data::T # T is the base type of the enum
end

In my benchmark, it is as fast and memory efficient as regular enums. They have also the same memory layout for the C code and can be used as a drop-in replacement. The user will still be able to use its own julia enum if it registered before hand with the function:

NCDatasets.typemap!(ds,"cloud_class_t" => Clouds.cloud_class_t); # or similar API

As we own the type NCEnum is also easier to provide a conversion function to CatagoricalArrays as a weak-extension.