MinMax projection allows to violate row policy

[CurtizJ]

Describe the unexpected behaviour
If we read from projection, row policy is disabled explicitly. It can be ok if we have added the projection explicitly (but still need to be documented), because it's unclear how to filter rows, since the row policy expression is set for original rows. But projection from minmax index is created implicitly and enabled by default and it's unexpected that it will allow to run some simple queries ignoring row policies.

How to reproduce

CREATE TABLE t(a UInt32, b UInt32) ENGINE = MergeTree PARTITION BY a ORDER BY a;

INSERT INTO t SELECT number % 10, number FROM numbers(10000);

CREATE ROW POLICY OR REPLACE rp ON default.t FOR SELECT USING 0 TO ALL;

SELECT count(), min(a), max(a) FROM t;

┌─count()─┬─min(a)─┬─max(a)─┐
│   10000 │      0 │      9 │
└─────────┴────────┴────────┘

SELECT count(), min(a), max(a), sum(a) FROM t;

┌─count()─┬─min(a)─┬─max(a)─┬─sum(a)─┐
│       0 │      0 │      0 │      0 │
└─────────┴────────┴────────┴────────┘


SET allow_experimental_projection_optimization = 0;

SELECT count(), min(a), max(a) FROM t;

┌─count()─┬─min(a)─┬─max(a)─┐
│       0 │      0 │      0 │
└─────────┴────────┴────────┘

Expected behavior
Do not use implicitly created projection if row policy is set.

[amosbird]

If we read from projection, row policy is disabled explicitly.

User defined projections support row policy properly, test

min_max_count projection is special when dealing with filters. It always uses PartitionPruner, which means related KeyCondition should be properly constructed. However, we don't support using row policy in any kind of index analysis yet.