**Describe the unexpected behaviour**

Not sure if it is a bug but we encounter a very strange issue when using the same field 2 times in a where clause.
Basically : field = <> and toYear(field)= <>

**How to reproduce**
* Clickhouse 20.5.2.7


Create table statement :
```
DROP TABLE IF EXISTS datasources.cal_pace_strange2;
CREATE TABLE datasources.cal_pace_strange2
(
    `htl_id` UInt32,
    `stay_date` Date,
    `snpdate` Date,
    `leadtime` String,
    `los` String,
    `mkt_id` String,
    `sob_id` String,
    `res_status_id` String,
    `rt_id` String,
    `cur` String,
    `rns` Decimal(9, 4),
    `arrivals` Decimal(9, 4),
    `departures` Decimal(9, 4),
    `adults` Decimal(9, 4),
    `children` Decimal(9, 4),
    `rm_rev` Decimal(18, 10),
    `fd_rev` Decimal(18, 10),
    `oth_rev` Decimal(18, 10),
    `tot_rev` Decimal(18, 10)

)
    ENGINE = MergeTree()
        PARTITION BY toYYYYMM(snpdate)
        ORDER BY (htl_id, stay_date, snpdate)
        SETTINGS index_granularity = 8192;
```

Load the data using the attached SQL inserts.

[data_bug_clickhouse.txt](https://github.com/ClickHouse/ClickHouse/files/4903808/data_bug_clickhouse.txt)


This query returns 0 results :

`select * from cal_pace_strange2 where snpdate='2020-06-09' and htl_id=66 and stay_date='2020-10-02' and toYear(stay_date) = 2020;`

This one return the correct results :

`select * from cal_pace_strange2 where snpdate='2020-06-09' and htl_id=66 and stay_date='2020-10-02'`

Same behavior occurs in 20.4.3 and 20.4.4

Expected behavior :

Both queries should return the same results.




if (select.where() && select.prewhere())
            filter_query = makeASTFunction("and", select.where(), select.prewhere());
        else
            filter_query = select.where() ? select.where() : select.prewhere();
        /** When non-strictly monotonic functions are employed in functional index (e.g. ORDER BY toStartOfHour(dateTime)),
          * the use of NOT operator in predicate will result in the indexing algorithm leave out some data.
          * This is caused by rewriting in KeyCondition::tryParseAtomFromAST of relational operators to less strict
          * when parsing the AST into internal RPN representation.
          * To overcome the problem, before parsing the AST we transform it to its semantically equivalent form where all NOT's
          * are pushed down and applied (when possible) to leaf nodes.
          */
        traverseAST(cloneASTWithInversionPushDown(filter_query), context, block_with_constants);
    }
    else
    {
        rpn.emplace_back(RPNElement::FUNCTION_UNKNOWN);
    }
}
bool KeyCondition::addCondition(const String & column, const Range & range)
{
    if (!key_columns.count(column))
        return false;
    rpn.emplace_back(RPNElement::FUNCTION_IN_RANGE, key_columns[column], range);
    rpn.emplace_back(RPNElement::FUNCTION_AND);
    return true;
}
/** Computes value of constant expression and its data type.
  * Returns false, if expression isn't constant.
  */
bool KeyCondition::getConstant(const ASTPtr & expr, Block & block_with_constants, Field & out_value, DataTypePtr & out_type)