**Unexpected behavior**
ATTACH PARTITION command fails when destination table's existing partition size is large than `max_partition_size_to_drop`

Attaching a tiny sample of few hundred rows from `db.source_table_sample` to `db.destination_table_full` fails because partition `202108` size is (53.46 GB) which is larger than default `max_partition_size_to_drop` (50GB)

Error message:
```sql
ALTER TABLE db.destination_table_full
    ATTACH PARTITION 202108 FROM db.source_table_sample

Query id: adf2c8fb-ba8a-4846-9c32-fabdb0d387b9


0 rows in set. Elapsed: 0.002 sec.

Received exception from server (version 21.7.11):
Code: 359. DB::Exception: Received from localhost:9440. DB::Exception: Table or Partition in db.destination_table_full was not dropped.
Reason:
1. Size (53.46 GB) is greater than max_[table/partition]_size_to_drop (50.00 GB)
2. File '/drives/ssd1/clickhouse/flags/force_drop_table' intended to force DROP doesn't exist
How to fix this:
1. Either increase (or set to zero) max_[table/partition]_size_to_drop in server config
2. Either create forcing file /drives/ssd1/clickhouse/flags/force_drop_table and make sure that ClickHouse has write permission for it.
Example:
sudo touch '/drives/ssd1/clickhouse/flags/force_drop_table' && sudo chmod 666 '/drives/ssd1/clickhouse/flags/force_drop_table'.
```

However, if I try to do the same in a new empty table `db.destination_table_sample`, it can attach partition successfully.

```sql
ALTER TABLE db.destination_table_sample
    ATTACH PARTITION 202108 FROM db.source_table_sample

Query id: f1567cf5-b1da-476c-aebb-3cf9f767849e

Ok.

0 rows in set. Elapsed: 0.003 sec.
```


How I calculated partition size:
```sql
SELECT
    partition,
    formatReadableSize(sum(bytes_on_disk)),
    round(((sum(bytes_on_disk) / 1000) / 1000) / 1000, 2) AS GB
FROM system.parts
WHERE table = 'destination_table_full'
GROUP BY partition

Query id: 33862450-3dd5-410e-aee0-30fbee339b68

┌─partition─┬─formatReadableSize(sum(bytes_on_disk))─┬────GB─┐
│ 202107    │ 2.07 GiB                               │  2.22 │
│ 202108    │ 49.79 GiB                              │ 53.46 │
│ 202110    │ 5.85 GiB                               │  6.28 │
│ 202109    │ 17.89 GiB                              │ 19.21 │
└───────────┴────────────────────────────────────────┴───────┘
```

**Expected behavior**
Partitions should be attached successfully regardless of `max_partition_size_to_drop` value

**How to reproduce**
ClickHouse server version: ClickHouse server version 21.7.11.3 (official build).
Which interface to use: clickhouse-client (I originally noticed this behavior in the logs of clickhouse-copier)
const StorageInMemoryMetadata & new_metadata, const StorageInMemoryMetadata & old_metadata, bool attach) const
{
    if (!new_metadata.sorting_key.definition_ast)
        throw Exception("ORDER BY cannot be empty", ErrorCodes::BAD_ARGUMENTS);
    KeyDescription new_sorting_key = new_metadata.sorting_key;
    KeyDescription new_primary_key = new_metadata.primary_key;
    size_t sorting_key_size = new_sorting_key.column_names.size();
    size_t primary_key_size = new_primary_key.column_names.size();
    if (primary_key_size > sorting_key_size)
        throw Exception("Primary key must be a prefix of the sorting key, but its length: "
            + toString(primary_key_size) + " is greater than the sorting key length: " + toString(sorting_key_size),
            ErrorCodes::BAD_ARGUMENTS);
    NameSet primary_key_columns_set;
    for (size_t i = 0; i < sorting_key_size; ++i)
    {
        const String & sorting_key_column = new_sorting_key.column_names[i];
        if (i < primary_key_size)
        {
            const String & pk_column = new_primary_key.column_names[i];
            if (pk_column != sorting_key_column)
                throw Exception("Primary key must be a prefix of the sorting key, but the column in the position "
                    + toString(i) + " is " + sorting_key_column +", not " + pk_column,
                    ErrorCodes::BAD_ARGUMENTS);
            if (!primary_key_columns_set.emplace(pk_column).second)
                throw Exception("Primary key contains duplicate columns", ErrorCodes::BAD_ARGUMENTS);
        }
    }
    auto all_columns = new_metadata.columns.getAllPhysical();