Given that vcounter is a View, the settings limit/offset dose not work as expected.

```sql
CREATE TABLE counter (id UInt64, createdAt DateTime) ENGINE = MergeTree() ORDER BY id;
INSERT INTO counter SELECT number, now() FROM numbers(500);

CREATE VIEW vcounter AS
SELECT
    intDiv(id, 10) AS tens,
    max(createdAt) AS maxid
FROM counter
GROUP BY tens;

SELECT *
FROM vcounter
ORDER BY tens ASC
LIMIT 100
SETTINGS limit = 6, offset = 5


┌─tens─┬───────────────maxid─┐
│   47 │ 2021-12-29 13:05:23 │
└──────┴─────────────────────┘

1 rows in set. Elapsed: 0.006 sec.

```

The query should return 6 rows, instead of one. 

**Does it reproduce on recent release?**

Yes, we can reproduce it on `21.10`.

**Expected behavior**

The query should return 6 rows, instead of one.

**Additional context**

Replace view with subquery works though,

```sql
SELECT *
FROM
(
    SELECT
        intDiv(id, 10) AS tens,
        max(createdAt) AS maxid
    FROM test.counter
    GROUP BY tens
)
LIMIT 100
SETTINGS limit = 6, offset = 5;

┌─tens─┬───────────────maxid─┐
│    3 │ 2021-12-29 13:05:23 │
│   31 │ 2021-12-29 13:05:23 │
│   47 │ 2021-12-29 13:05:23 │
│   40 │ 2021-12-29 13:05:23 │
│   30 │ 2021-12-29 13:05:23 │
│    2 │ 2021-12-29 13:05:23 │
└──────┴─────────────────────┘

6 rows in set. Elapsed: 0.011 sec. 
```

{
    const auto & header_before_merge = query_plan.getCurrentDataStream().header;
    ColumnNumbers keys;
    for (const auto & key : aggregation_keys)
        keys.push_back(header_before_merge.getPositionByName(key.name));
    /** There are two modes of distributed aggregation.
      *
      * 1. In different threads read from the remote servers blocks.
      * Save all the blocks in the RAM. Merge blocks.
      * If the aggregation is two-level - parallelize to the number of buckets.
      *
      * 2. In one thread, read blocks from different servers in order.
      * RAM stores only one block from each server.
      * If the aggregation is a two-level aggregation, we consistently merge the blocks of each next level.
      *
      * The second option consumes less memory (up to 256 times less)
      *  in the case of two-level aggregation, which is used for large results after GROUP BY,
      *  but it can work more slowly.
      */
    Aggregator::Params params(header_before_merge, keys, aggregates, overflow_row, settings.max_threads);
    auto transform_params = std::make_shared<AggregatingTransformParams>(params, final);
    auto merging_aggregated = std::make_unique<MergingAggregatedStep>(
        query_plan.getCurrentDataStream(),
        std::move(transform_params),
        settings.distributed_aggregation_memory_efficient && is_remote_storage,
        settings.max_threads,
        settings.aggregation_memory_efficient_merge_threads);
    query_plan.addStep(std::move(merging_aggregated));
}
void InterpreterSelectQuery::addEmptySourceToQueryPlan(