Switch to using EqualsExact in geometry comparer

[roji]

Fixes #18921

[bricelam]

We should review the translations for the various equals methods too

[roji]

Yeah.

Here's a useful PostGIS page on the different kind of equalities etc: https://postgis.net/workshops/postgis-intro/equality.html

Npgsql translates EqualsExact to the PostGIS equality operator, and EqualsTopologically to PostGIS ST_Equals. After reading the equality page above it seems like translating EqualsExact to ST_OrderingEquals may be more correct...

[roji]

Opened npgsql/efcore.pg#1131 for the Npgsql side.

[roji]

@bricelam checked and there don't appear to be translations of EqualsExact for either SQL Server or Sqlit (SQL Server doesn't even allow equals operator: Invalid operator for data type. Operator equals equal to, type equals geometry.)...

Will do the translation in Npgsql (is it worth adding tests in SpatialQueryTestBase test suite if neither provider will actually exercise them...).

BTW all the tests in SpatialQueryTestBase have the tested expression in a top-level projection, which is a bit dangerous since it will do client evaluation for providers which don't translate. Any reason not to exercise them in a Where clause instead?

[bricelam]

You can add a test to the base to encourage other providers to implement it if possible.

Using Where got too tricky since precision, etc. was very different between providers. I decided asserting the SQL and loosely verifying the result was the most pragmatic thing to do.