This is a regression from the bug fix for bug no. 14358878.
The fix for that bug was basically to add the nullable property
for any Item_direct_view_ref object that would wrap an Item
selected from a derived table/view reference placed on the
inner side of an outer join, and letting the null value be
calculated at run time by looking at the NULL status of the first
table of the derived table.

This works well when the derived table is a single table, or an
inner join, or a left outer join. However, if the derived table
is itself a right outer join, the first table of the derived table
may be the inner table of the right outer join, and that table may
contain a NULL row even though the derived table as a whole is
producing a row.

Thus, we can get a NULL indication even though the derived table
is producing a row, if the inner table of the right outer join that
is part of that derived table is null-extended.

The solution to the problem is to locate a table within the
derived table that is not outer-joined within the derived table,
ie locate a table that does not have the outer_join property set.
A new function TABLE_LIST::any_outer_leaf_table() is implemented
to locate such a table.

Notice that this bug is limited to derived tables: A view has the
same properties as a derived table, but there is one important
difference: When the view is created, its join nests are normalized
so that right joins are converted into left joins. Hence, the
first table of the derived table nest will always be an "outer" table,
which is good for our calculation. An alternative solution might thus
be to normalize derived tables like views.

(Derived tables are indeed right-join normalized, but the normalization
is limited to the join_list structures, and not the table_list
structures, which are used when navigating tables contained in
a view/derived table. Whereas views are normalized when written to
stored dictionary and table_list is reconstructed based on the
normalized form when view is included into a query.)