perf: Implement (2x) faster ST_Buffer kernel using geo

[petern48]

closes #232

Performance is about 2x faster:

sedona-geos

geos-st_buffer-ArrayScalar(Polygon(10), Float64(1.0, 10.0))
                        time:   [1.2389 s 1.2621 s 1.2871 s]

geos-st_buffer-ArrayScalar(Polygon(50), Float64(1.0, 10.0))
                        time:   [2.3664 s 2.3742 s 2.3825 s]

sedona-geo (this PR)

geo-st_buffer-ArrayScalar(Polygon(10), Float64(1.0, 10.0))
                        time:   [597.68 ms 613.95 ms 632.17 ms]

geo-st_buffer-ArrayScalar(Polygon(50), Float64(1.0, 10.0))
                        time:   [1.1246 s 1.1285 s 1.1327 s]

[petern48]

The test suite here is the same as the geos buffer test suite plus this new function, which I also copied over to geos st_buffer to be sure it works the same.

[petern48]

I was running into an error here with POINT EMPTY since geo apparently doesn't support it.

sedona-db/rust/sedona-geo/src/to_geo.rs

Lines 62 to 66 in 3d75664

	not_impl_err!(
	"geo kernel implementation on {}, {}, or {} not supported",
	"MULTIPOINT with EMPTY child",
	"POINT EMPTY",
	"GEOMETRYCOLLECTION"

My current workaround is to use WKBExecutor here instead of GeoTypesExecutor and use our native is_geometry_empty check.

Wondering if there's a better way we can handle empty points in our item_to_geometry() method. The docstring for geo's try_to_point() function we are in there says returning None represents an empty point. Though returning None is not a safe option, so I can't think of anything better than this workaround atm.

[petern48]

Are there any convenient existing ways to benchmark this against the geos implementation? I'm not aware of any. Not yet sure if this is faster or not

[paleolimbot]

Are there any convenient existing ways to benchmark this against the geos implementation?

This should work:

# on main
cargo bench -- st_buffer
# switch to your branch
cargo bench -- st_buffer

[petern48]

Looks like this is indeed faster. I've updated the PR description with the benchmark results.