Incorrect handling of NULL join conditions when using split-materialized

During the optimization phase, when determining whether or not to materialize a derived table
all at once or in groups (split materialization), all key equalities that reference the derived table have their cond Items pushed into JOIN::spl_opt_info->inj_cond_list.
From there they are filtered (tables in join prefix) and injected into the JOIN conditions (in JOIN::inject_best_splitting_cond()), where they might (they are in the test case) be removed because they are involved in the grouping operation and they aren't needed.
If they aren't removed, then we might have a non-null safe equality in our join conditions where we should have a null safe one.