Added test for Bug #11521

"Negative integer keys incorrectly substituted for 0 during range analysis."

The problem is that the range optimizer incorrectly replaces any negative
constant with '0' for all types except BIGINT because the method save_in_field()
casts negative integers to non-negative. This causes incorrect query
results where (0 = any_negative_number).

The problem caused by this bug is fixed by the patch for BUG#11185.
That patch constitutes an optimization due to which the problem code is
never called with negative constants. This patch adds a test so we are sure
that the problem does not reappear.

mysql-test/r/select.result

@@ -2570,3 +2570,15 @@ f2
 1
 NULL
 drop table t1,t2;
+create table t2 (a tinyint unsigned);
+create index t2i on t2(a);
+insert into t2 values (0), (254), (255);
+explain select * from t2 where a > -1;
+id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
+1	SIMPLE	t2	index	t2i	t2i	2	NULL	3	Using where; Using index
+select * from t2 where a > -1;
+a
+0
+254
+255
+drop table t2;

mysql-test/t/select.test

@@ -2127,3 +2127,14 @@ insert into t2 values (1,2,3),(2,4,6);
 select A.f2 from t1 left join t2 A on A.f2 = f1 where A.f3=(select min(f3)
 from  t2 C where A.f4 = C.f4) or A.f3 IS NULL; 
 drop table t1,t2;
+
+#
+# Bug #11521 Negative integer keys incorrectly substituted for 0 during
+#            range analysis.
+
+create table t2 (a tinyint unsigned);
+create index t2i on t2(a);
+insert into t2 values (0), (254), (255);
+explain select * from t2 where a > -1;
+select * from t2 where a > -1;
+drop table t2;