Crash by `INNER JOIN`

[suyZhong]

The following test case crashed go-mysql-server.

CREATE TABLE t0(c0 VARCHAR(500));
CREATE TABLE t1(c0 INTEGER, PRIMARY KEY(c0));
INSERT INTO t1(c0) VALUES (0);
INSERT INTO t0(c0) VALUES ('a');
INSERT INTO t1(c0) VALUES (1);

SELECT * FROM t1 INNER  JOIN t0 ON ((t0.c0)=(t1.c0));

Here's the error trace:

panic: runtime error: slice bounds out of range [:4] with capacity 2

goroutine 741 [running]:
github.com/dolthub/dolt/go/store/val.DefaultTupleComparator.Compare({}, {0xc0040877ba, 0x2, 0x2}, {0xc004024d9a, 0x6, 0x66}, {{0xc004087838, 0x1, 0x4}, ...})
        /home/suyang/Repos/dolt/go/store/val/tuple_compare.go:46 +0x306
github.com/dolthub/dolt/go/store/val.TupleDesc.Compare({{0xc004087838, 0x1, 0x4}, {0x31abb20, 0x5d88500}, {0xc00408784c, 0x1, 0x1}}, {0xc0040877ba, 0x2, ...}, ...)
        /home/suyang/Repos/dolt/go/store/val/tuple_descriptor.go:132 +0xcb
github.com/dolthub/dolt/go/store/prolly/tree.newLeafCursorAtKey[...]({0x31a84c0, 0xc00409e960}, {0x31af1a0, _}, {{0x68, 0xc, 0x5c, 0x6, 0x0}, {0x54, ...}, ...}, ...)
        /home/suyang/Repos/dolt/go/store/prolly/tree/node_cursor.go:192 +0x529
github.com/dolthub/dolt/go/store/prolly/tree.StaticMap[...].GetPrefix(0x3255860, {0x31a84c0?, 0xc00409e960?}, {0xc0040877ba, 0x2, _}, {{0xc004087838, 0x1, 0x4}, {0x31abb20, ...}, ...}, ...)
        /home/suyang/Repos/dolt/go/store/prolly/tree/map.go:246 +0x125
github.com/dolthub/dolt/go/store/prolly.Map.GetPrefix(...)
        /home/suyang/Repos/dolt/go/store/prolly/tuple_map.go:262
github.com/dolthub/dolt/go/libraries/doltcore/sqle/index.(*baseLookupBuilder).newPointLookup(0xc0015e45f0?, 0x1?, {{0xc004476820, 0x1, 0x1}, {{0xc004087588, 0x1, 0x4}, {0x31abb20, 0x5d88500}, ...}, ...})
        /home/suyang/Repos/dolt/go/libraries/doltcore/sqle/index/index_lookup.go:364 +0x1b7
github.com/dolthub/dolt/go/libraries/doltcore/sqle/index.(*baseLookupBuilder).rangeIter(0x0?, 0x0?, {0x3191ba0?, 0xc004474980?})
        /home/suyang/Repos/dolt/go/libraries/doltcore/sqle/index/index_lookup.go:378 +0x23b
github.com/dolthub/dolt/go/libraries/doltcore/sqle/index.(*coveringLookupBuilder).NewRowIter(0xc0044768c0, 0x124420bca87861d5?, {0x3191ba0?, 0xc004474980?})
        /home/suyang/Repos/dolt/go/libraries/doltcore/sqle/index/index_lookup.go:403 +0x45
github.com/dolthub/dolt/go/libraries/doltcore/sqle.(*WritableIndexedDoltTable).PartitionRows(0xc004089c00, 0x7fac56d6ca68?, {0x3191ba0, 0xc004474980})
        /home/suyang/Repos/dolt/go/libraries/doltcore/sqle/indexed_dolt_table.go:161 +0x28f
github.com/dolthub/go-mysql-server/sql.(*TableRowIter).Next(0xc00447e1c0, 0xc00409e960)
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/sql/table_iter.go:57 +0x137
github.com/dolthub/go-mysql-server/sql/rowexec.(*joinIter).loadSecondary(0xc00409f0e0, 0x0?)
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/sql/rowexec/join_iters.go:112 +0xd1
github.com/dolthub/go-mysql-server/sql/rowexec.(*joinIter).Next(0xc00409f0e0, 0x0?)
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/sql/rowexec/join_iters.go:136 +0x70
github.com/dolthub/go-mysql-server/sql.CountingRowIter.Next({{0x319d458?, 0xc00409f0e0?}, 0xc004057220?}, 0x0?)
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/sql/describe.go:84 +0x2e
github.com/dolthub/go-mysql-server/sql/rowexec.(*projectIter).Next(0xc00447c780, 0x0?)
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/sql/rowexec/rel_iters.go:512 +0x29
github.com/dolthub/go-mysql-server/sql/rowexec.transactionCommittingIter.Next(...)
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/sql/rowexec/transaction_iters.go:78
github.com/dolthub/go-mysql-server/sql/plan.(*trackedRowIter).Next(0xc004089f80, 0x0?)
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/sql/plan/process.go:347 +0x24
github.com/dolthub/go-mysql-server/server.(*Handler).doQuery.func2()
        /home/suyang/go/pkg/mod/github.com/dolthub/go-mysql-server@v0.17.1-0.20240118235014-7dca45ad91fc/server/handler.go:359 +0x125
golang.org/x/sync/errgroup.(*Group).Go.func1()
        /home/suyang/go/pkg/mod/golang.org/x/sync@v0.3.0/errgroup/errgroup.go:75 +0x56
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 77
        /home/suyang/go/pkg/mod/golang.org/x/sync@v0.3.0/errgroup/errgroup.go:72 +0x96

I originally found this by building dolt from source version 9360c4e

[max-hoffman]

Test with the forced lookup and order required to trigger the error path:

{
			Name: "range query convert int to string zero value",
			SetUpScript: []string{
				`CREATE TABLE t0(c0 VARCHAR(500));`,
				`CREATE TABLE t1(c0 INTEGER, PRIMARY KEY(c0));`,
				`INSERT INTO t1(c0) VALUES (0);`,
				`INSERT INTO t0(c0) VALUES ('a');`,
				`INSERT INTO t1(c0) VALUES (1);`,
			},
			Assertions: []queries.ScriptTestAssertion{
				{
					Query:    "SELECT /*+ LOOKUP_JOIN(t0,t1) JOIN_ORDER(t0,t1)  */ * FROM t1 INNER  JOIN t0 ON ((t0.c0)=(t1.c0));",
					Expected: []sql.Row{{"a"}},
				},
			},
		},

This will either need to be a Dolt specific test or we'll need to add a validation layer to the engine lookup machinery.

plan:

Project
 ├─ columns: [t1.c0:1!null, t0.c0:0]
 └─ LookupJoin
     ├─ Table
     │   ├─ name: t0
     │   ├─ columns: [c0]
     │   ├─ colSet: (2)
     │   └─ tableId: 2
     └─ IndexedTableAccess(t1)
         ├─ index: [t1.c0]
         ├─ keys: [t0.c0:0]
         ├─ colSet: (1)
         ├─ tableId: 1
         └─ Table
             ├─ name: t1
             └─ columns: [c0]

This is conceptually related to #7372. What do we do when a lookup type is incompatible with the comparand type? Should we be coercing the lookup value to the zero value of the comparand type? Are there static rules we can use to rewrite the lookup, for example, to just the zero range for the target type? Is the directionality of this relationship commutative (the query doesn't error if we force JOIN_ORDER(t1,t0) above)? Or do certain types take precedence for zero conversion? Are there character set and collation considerations when, for example, we have two otherwise compatible varchar types but the collations are different (lots of potential edge cases here).

[jycor]

This PR fixes the queries mentioned in this issue:
dolthub/go-mysql-server#2294

However, the fix is more of a point fix and does not fully address the varierty of type comparisons used in indexes.
Namely, we do not do truncation when converting from string types to numerical types, so it is still possible to generate queries that will produce incorrect results depending on the filter and the types used.

Fortunately, the fix will prevent panics of this nature.

[timsehn]

We'll resolve this given the path no longer panics.