MDEV-20501: Assertion `maybe_null || !null_value' failed in Item_func_round::date_opbb-10.4-mdev20501-v2

When the optimizer finds a constant (or system) table $TBL which is empty
or has no matching row, it would set table->null_row=true. This is done
even for tables with table->maybe_null==0.

Then, it would proceed to perform query optimization phases (what for?)
which will attempt to evaluate Item expressions referring to $TBL.

Eventually some Item expression will get the value of $TBL.not_null_field,
get SQL NULL and fail an assertion.

Fixed by not performing any query optimization steps after we've got
constant/empty tables with no matching rows.

Test result changes contain a lot of changes like
- ... Impossible WHERE noticed after reading const tables
+ ... no matching row in const table

as well as other changes caused by slightly-different processing of
the special case of empty constant tables.

1 files changed, 1 insertions, 0 deletions

diff --git a/sql/sql_union.cc b/sql/sql_union.cc
index 0f218b73b16..286adb8b257 100644
--- a/sql/sql_union.cc
+++ b/sql/sql_union.cc
@@ -1740,6 +1740,7 @@ bool st_select_lex_unit::exec()
         if (describe)
         {
           /*
+            UglySubqueryReoptimization:
             In EXPLAIN command, constant subqueries that do not use any
             tables are executed two times:
              - 1st time is a real evaluation to get the subquery value