MDEV-40553: unprintable gis ranges in trace and context

[bsrikanth-mariadb]

When ranges were specified in a query for GIS types, the recorded trace
and context couldn't print the range information. Instead, it only
showed unprintable_geometry_value.

This PR extends the geometric field type Field_geom to print key value
in binary form (same as what is done for Blobs today), along with the
comparison operator, when recorded in the range.
For spatial indexes, the operators like MBRWITHIN, MBRCONTAINS, etc...
are stored appropriately, and for normal indexes, operators like
<, <=, >, >=, etc... are recorded appropriately.

Implementation Details: -
Add an argument imagetype to Field::print_key_part_value(), to determine
if an index key part value is to be printed in WKT or binary format.
For Geometric type, imagetype is set to itMBR. When printing ranges,
the MBR operators are printed as well, as implemented in
print_mbr_range_operator().

[spetrunia]

Please apply this cleanup patch.
mdev-40553-cleanup.patch

Please fix typos in the commit comment: "MDRWITHIN, MDRCONTAINS"...

[spetrunia]

Please remove Field_geom::print_key_value(). I think it is not a good idea to print geometry values.

When the lookups are done, binary values are interpreted as BINARY(n) values and so should be printed as such.
Example: let's take two identical geometries:

SET @g1 = ST_GeomFromText('LINESTRING(1 1, 2 2)');
SET @g2 = ST_GeomFromText('LINESTRING(2 2, 1 1)');

MariaDB [test]> SELECT ST_Equals(@g1, @g2);
+---------------------+
| ST_Equals(@g1, @g2) |
+---------------------+
|                   1 |
+---------------------+
1 row in set (0.001 sec)

However their binary representation is not identical:

MariaDB [test]> select hex(@g1) = hex(@g2);
+---------------------+
| hex(@g1) = hex(@g2) |
+---------------------+
|                   0 |
+---------------------+
1 row in set (0.001 sec)