[WIP] feat: use rust-warp instead of pyproj + numpy for reprojection

[hrodmn]

I just wanted to test this out to see how much faster the rust-based resampling approach would be for lazycogs.

cc @jakenotjay @sharkinsspatial

[github-actions]

Benchmark Comparison

End-to-end benchmarks

Test	Baseline (ms)	PR (ms)	Change
test_band_access_pattern[multi_band]	1447.8	501.4	-65.4%
test_band_access_pattern[single_band]	1330.8	433.0	-67.5%
test_full_compute	739.5	395.0	-46.6%
test_mosaic_method[first]	701.9	395.0	-43.7%
test_mosaic_method[median]	753.1	438.2	-41.8%
test_native_crs_resolution	11367.1	1322.0	-88.4%
test_open_overhead	314.3	271.5	-13.6%
test_reproject_workers[1]	1483.9	502.9	-66.1%
test_reproject_workers[4]	1499.6	504.2	-66.4%
test_time_step_parallelism[dask_time_1]	1461.6	499.4	-65.8%
test_time_step_parallelism[no_dask]	1025.6	465.4	-54.6%

New benchmarks in PR

• test_small_window_nearest_reprojection
• test_small_window_reprojection_modes[bilinear]
• test_small_window_reprojection_modes[cubic]
• test_small_window_reprojection_modes[nearest]
• test_small_window_reprojection_modes[same_grid_noop]

[kylebarron]

I wonder if we could have some internal protocols that we use for "generic" warping, so that we don't over-index on the rust-warp API specifically?

[jakenotjay]

Very cool to see this btw, had no expectation this would go anywhere. Assume you've got some correctness checks in here @hrodmn?

Lmk if you need anything added/removed, it was very much tied to my usecase of odc-geobox based reprojects.

[hrodmn]

Assume you've got some correctness checks in here @hrodmn?

Yes! I added some tests to compare the lazycogs reprojection to rasterio in test_rasterio_parity.py, those tests got updated to compare against the rust-warp approach in this PR and things are looking good.

I wonder if we could have some internal protocols that we use for "generic" warping, so that we don't over-index on the rust-warp API specifically?

Yeah this is just what I could whip up yesterday to test out the idea of swapping out our python warping approach with a rust warping approach. My take is that the rust approach is a lot faster and more efficient than the python approach. I did some more integration testing and performance improved quite a bit for some cases so it is definitely worth pursuing further. The benchmark results above ^ reflect the potential improvement (in a non-network-bound scenario).

We should not merge this as-is. I would want to wait to finalize the structure until there is an actual release of rust-warp (or some other package)!

I'll probably close this PR for now while we come up with a plan for rust-based warping in the broader ecosystem - I know there are several other projects where this is of interest so we will want to spend some time considering the right API design. warp-rust seems like a great start though!