MDEV-9457: Poor query plan chosen for ORDER BY query by a recent 10.1

Undo the change in test_if_skip_sort_order() that set ref_key=-1 when
a variant of index_merge is used (was made in fix for MDEV-9021).

It turned out that test_if_cheaper_ordering() call below assumes that
ref_key=-1 means "no index is used", that is, "an inefficient full table
scan is done".
This is not the same as index_merge, index_merge can actually be quite
efficient. So, ref_key=MAX_KEY denotes the fact that some index is used,
not any given index.

mysql-test/r/order_by_innodb.result

@@ -11,3 +11,40 @@ a	b	c	d
 8	NULL	9	NULL
 8	NULL	10	NULL
 DROP TABLE t1;
+#
+# MDEV-9457: Poor query plan chosen for ORDER BY query by a recent 10.1
+#
+create table t0 (a int);
+insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
+create table t1 (
+pk int primary key,
+key1 int,
+key2 int,
+col1 char(255),
+key(key1),
+key(key2)
+) engine=innodb;
+set @a=-1;
+insert into t1 
+select 
+@a:=@a+1, 
+@a, 
+@a, 
+repeat('abcd', 63) 
+from t0 A, t0 B, t0 C, t0 D;
+# The following must NOT use 'index' on PK. 
+# It should use index_merge(key1,key2) + filesort
+explain 
+select * 
+from t1
+where key1<3 or key2<3
+order by pk;
+id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
+1	SIMPLE	t1	index_merge	key1,key2	key1,key2	5,5	NULL	#	Using sort_union(key1,key2); Using where; Using filesort
+explain 
+select * 
+from t1
+where key1<3 or key2<3;
+id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
+1	SIMPLE	t1	index_merge	key1,key2	key1,key2	5,5	NULL	#	Using sort_union(key1,key2); Using where
+drop table t0, t1;