- The problem was that the code that made the check whether the subquery is an AND-part of the WHERE 
  clause didn't work correctly for nested subqueries. In particular, grand-child subquery in HAVING was 
  treated as if it was in the WHERE, which eventually caused an assert when replace_where_subcondition
  looked for the subquery predicate in the WHERE and couldn't find it there.

- The fix: Removed implementation of "thd_marker approach". thd->thd_marker was used to determine the 
  location of subquery predicate: setup_conds() would set accordingly it when making the 

    {where|on_expr}->fix_fields(...)

  call so that AND-parts of the WHERE/ON clauses can determine they are the AND-parts. 
  Item_cond_or::fix_fields(), Item_func::fix_fields(), Item_subselect::fix_fields (this one was missed),
  and all other items-that-contain-items had to reset thd->thd_marker before calling fix_fields() for 
  their children items, so that the children can see they are not AND-parts of WHERE/ON.
- The "thd_marker approach" required that a lot of code in different locations maintains correct value of
  thd->thd_marker, so it was replaced with:
- The new approach with mark_as_condition_AND_part does not keep context in thd->thd_marker. Instead, 
  setup_conds() now calls

    {where|on_expr}->mark_as_condition_AND_part()

  and implementations of that function make sure that: 
   - parts of AND-expressions get the mark_as_condition_AND_part() call
   - Item_in_subselect objects record that they are AND-parts of WHERE/ON