MDEV-34123 CONCAT Function Returns Unexpected Empty Set in Query

Search conditions were evaluated using val_int(), which was wrong.
Fixing the code to use val_bool() instead.

Details:
- Adding a new item_base_t::IS_COND flag which marks Items used
  as <search condition> in WHERE, HAVING, JOIN ON, CASE WHEN clauses.
  The flag is at the parse time.
  These expressions must be evaluated using val_bool() rather than val_int().

  Note, the optimizer creates more Items which are used as search conditions.
  Most of these items are not marked with IS_COND yet. This is OK for now,
  but eventually these Items can also be fixed to have the flag.

- Adding a method Item::is_cond() which tests if the Item has the IS_COND flag.

- Implementing Item_cache_bool. It evaluates the cached expression using
  val_bool() rather than val_int().
  Overriding Type_handler_bool::Item_get_cache() to create Item_cache_bool.

- Implementing Item::save_bool_in_field(). It uses val_bool() rather than
  val_int() to evaluate the expression.

- Implementing Type_handler_bool::Item_save_in_field()
  using Item::save_bool_in_field().

- Fixing all Item_bool_func descendants to implement a virtual val_bool()
  rather than a virtual val_int().

- To find places where val_int() should be fixed to val_bool(), a few
  DBUG_ASSERT(!is_cond()) where added into val_int() implementations
  of selected (most frequent) classes:

  Item_field
  Item_str_func
  Item_datefunc
  Item_timefunc
  Item_datetimefunc
  Item_cache_bool
  Item_bool_func
  Item_func_hybrid_field_type
  Item_basic_constant descendants

- Fixing all places where DBUG_ASSERT() happened during an "mtr" run
  to use val_bool() instead of val_int().

sql/sql_type.cc

@@ -4363,6 +4363,13 @@ int Type_handler_int_result::Item_save_in_field(Item *item, Field *field,
 }
 
 
+int Type_handler_bool::Item_save_in_field(Item *item, Field *field,
+                                          bool no_conversions) const
+{
+  return item->save_bool_in_field(field, no_conversions);
+}
+
+
 /***********************************************************************/
 
 bool Type_handler_row::
@@ -4523,6 +4530,12 @@ Type_handler_int_result::Item_get_cache(THD *thd, const Item *item) const
   return new (thd->mem_root) Item_cache_int(thd, item->type_handler());
 }
 
+Item_cache *
+Type_handler_bool::Item_get_cache(THD *thd, const Item *item) const
+{
+  return new (thd->mem_root) Item_cache_bool(thd);
+}
+
 Item_cache *
 Type_handler_year::Item_get_cache(THD *thd, const Item *item) const
 {
@@ -5153,7 +5166,22 @@ bool Type_handler_real_result::Item_val_bool(Item *item) const
 
 bool Type_handler_int_result::Item_val_bool(Item *item) const
 {
-  return item->val_int() != 0;
+  /*
+    Some Item descendants have DBUG_ASSERT(!is_cond()) is their
+    val_int() implementations, which means val_int() must not be used
+    to evaluate a condition: val_bool() must be used instead.
+    If we come here, it means item's class does not override val_bool()
+    and we need to evaluate the boolean value from the integer value
+    as a fall-back method. To avoid the assert, let's hide the IS_COND flag.
+    Eventually we'll need to implement val_bool() in all Item descendants and
+    remove the trick with flags. This change would be too ricky for 10.6.
+    Let's do it in a later version.
+  */
+  item_base_t flags= item->base_flags;
+  item->base_flags &= ~item_base_t::IS_COND;
+  bool rc= item->val_int() != 0;
+  item->base_flags= flags;
+  return rc;
 }
 
 bool Type_handler_temporal_result::Item_val_bool(Item *item) const