Possibly merge `RegularChunks` and `IrregularChunks` into a single struct

[meggart]

I am currently working on improving the performance and type-stability of the ConcatDiskArray constructor and one major unavoidable source of type instability is that we can not know a priori if the resulting array will have regular or irregular chunks. There would be 2 ways to work around this:

1. always assume the resulting array will have irregular chunks, this would imply (moderate) performance penalties for chunk lookups when the resulting concat array would have regular chunks
2. merge RegularChunks and IrregularChunks into a single struct which works like a hand-coded union and that might look like this:

struct Chunks
is_regular::Bool
arraysize::Int
chunksize::Int
offset::Int
irregular_offsets::Vector{Int}
end

Depending on if we construct a regular or irregular chunk object along a dimension, the is_regular flag is set and either chunksize and offset or the irregular_offsets fields are filled with meaningful values. All getindex methods would need to dynamically check the is_regular flag, which should be cheap and then call the respective routines. As a result, we would be back to a single ChunkVector representation, we could remove the second type parameter from ChunkVector and have the whole chunk machinery quite inherently type-stable. Would also be interesting in the light of movement towards more type-stable IO APIs compatible with static compilation and experiments like this one: https://github.com/gbaraldi/StaticHDF5.jl @rafaqz what do you think?

[rafaqz]

How bad is this instability in practice?

Rasters.jl has a lot of similar type instability for NetCDF because there are so many options and Dimensional data.jl uses types to distinguish them. We lose a bit of time on load but then indexing and everything else is much faster.

[meggart]

In practise there will be no measurable benefit for normal Julia applications.

The question is rather a design decision: Do we think that DiskArrays.jl should try avoid dynamic dispatch in most places so that it can be used in statically compiled applications that involve some level of IO or do we decide against this and continue to write convenient unstable code for one-time tasks like the creation of concatenated arrays, but in return have have highly specialized types afterwards that make subsequent operations most efficient.

I think DimensionalData has made this decision by putting almost everything possible trait into Dim and Lookup types, so a loading a DimArray in a type-stable way would be very inconvenient for the user as they would need to specify all these traits by hand when constructing the axes. I am just not sure if we should go the same way for DiskArrays, pinging @asinghvi17 here as he recently suggested to consider making a type-stable Zarr interface.

[asinghvi17]

I think we could get the best of both worlds by making this RuntimeChunks a subtype of AbstractChunks, that readers can choose to report from eachchunk if people want to run in type stable mode. This way we can be compatible with "type stable" but slower runtime chunks, while also having the fastest possible speed for people who are running, as most people will, in regular Julia.

[rafaqz]

I think one type is actually fine for DiskArrays, it's a relatively low overhead. Having fields for both and a Bool flag seems reasonable to me.

DD has much different performance pressures than DiskArrays and a lot more complex objects to represent. Indexing with names is zero cost, and at that point we have just chosen compile time types.