feat(rust/sedona-raster-gdal): RS_ZonalStats and RS_ZonalStatsAll

[james-willis]

Experimental RS_ZonalStats and RS_ZonalStatsAll (ported from #704), matching Sedona Spark's positional overload ladder.

[paleolimbot]

I think some thought about the corner cases of stats handling (and how this is done in non-Sedona Spark places) should be considered here before this merges, but in general this looks great!

[paleolimbot]

Is this mask heap allocated / would it benefit from scratch space in a loop since it's temporary?

[paleolimbot]

Maybe a helper class in a separate file like

struct StatsEvaluator<T> {
    values: Vec<T>,
    values_sorted: bool,
    count: i64,
    current_sum: Option<T>,
}

impl <T> for StatsEvaluator<T> {
     fn sum(&mut self) -> T {
         if let Some(cached_sum) = self.current_sum {
             cached_sum
         } else { // if floating point, sort values first, then compute sum and cache it }
     }
}

...or something. That will let you benchmark and test it independently, perhaps against an existing library that has spent some time considering the corner cases of (instead of going on hunches about what will or won't be faster or correct). This approach would also let you be lazy about computing stats (instead of computing all of them for every case and discarding all except one in the case of RS_ZonalStats).

You could have one lazily constructed cached StatsEvaluator for each RasterDataType (for most cases there will only be one data type per batch so this won't explode scratch space).

[paleolimbot]

Thank you!

Float64 as a working type works for me (it's what GDAL does), although it would be good to check at least one adversarial example where the input is all INT64_MAX (if there isn't one already that I missed) to make sure we don't get a panic anywhere. I suggested a minor tweak to avoid a few passes over the data that shouldn't be too hard.