**Describe the situation**
hasAll() filter condition not relying on bloom filter, but re-writing as series of has() AND has()... (or series of indexOf conditions) does use bloom filter 

**How to reproduce**
* ClickHouse server version: 21.2.7.2

Test Table: 
- 33M records, 10 columns
- MergeTree() engine, has a sort order specified
- Has a field STRING_ARRAY that is a Array(String) column. It has a bloom filter data-skipping index (`TYPE bloom_filter(0.01) GRANULARITY 1`)

The following query takes 1.5 seconds: 
```
SELECT * FROM db_name.table_name
WHERE hasAll(STRING_ARRAY, ['value_1', 'value_2', 'value_3']
```
Running `EXPLAIN indexes = 1`, only the primary key is picked up. The bloom filter isn't used. 

The following query takes 0.45 seconds: 
```
SELECT * FROM db_name.table_name
WHERE has(STRING_ARRAY, 'value_1') AND has(STRING_ARRAY, 'value_2') AND has(STRING_ARRAY, 'value_3')
```
Running `EXPLAIN indexes = 1`, the bloom filter is used. 

**Expected performance**
Expecting the hasAll() filter condition to also get performance improvement from the bloom filter on STRING_ARRAY. 

{
    if (header.has(node->getColumnName()))
    {
        const auto & column_and_type = header.getByName(node->getColumnName());
        const auto & prepared_set_it = query_info.sets.find(getPreparedSetKey(node, column_and_type.type));
        if (prepared_set_it != query_info.sets.end() && prepared_set_it->second->hasExplicitSetElements())
            return prepared_set_it->second;
    }
    else
    {
        for (const auto & prepared_set_it : query_info.sets)
            if (prepared_set_it.first.ast_hash == node->getTreeHash() && prepared_set_it.second->hasExplicitSetElements())
                return prepared_set_it.second;
    }
    return DB::SetPtr();
}
}