Cancel MPPQuery should take effect in MPPGather's level

[windtalker]

Enhancement

Sometimes in TiDB a query will generate multiple standalone "mpp sub-queries", for example:

mysql> explain select * from test a join (select * from test limit 10) b on a.id = b.id;
+------------------------------------+------------+--------------+---------------+----------------------------------------------------+
| id                                 | estRows    | task         | access object | operator info                                      |
+------------------------------------+------------+--------------+---------------+----------------------------------------------------+
| HashJoin_13                        | 3506304.00 | root         |               | inner join, equal:[eq(test.test.id, test.test.id)] |
| ├─Selection_22(Build)              | 8.00       | root         |               | not(isnull(test.test.id))                          |
| │ └─Limit_25                       | 10.00      | root         |               | offset:0, count:10                                 |
| │   └─TableReader_33               | 10.00      | root         |               | MppVersion: 2, data:ExchangeSender_32              |
| │     └─ExchangeSender_32          | 10.00      | mpp[tiflash] |               | ExchangeType: PassThrough                          |
| │       └─Limit_31                 | 10.00      | mpp[tiflash] |               | offset:0, count:10                                 |
| │         └─TableFullScan_30       | 10.00      | mpp[tiflash] | table:test    | keep order:false                                   |
| └─TableReader_21(Probe)            | 524288.00  | root         |               | MppVersion: 2, data:ExchangeSender_20              |
|   └─ExchangeSender_20              | 524288.00  | mpp[tiflash] |               | ExchangeType: PassThrough                          |
|     └─Selection_19                 | 524288.00  | mpp[tiflash] |               | not(isnull(test.test.id))                          |
|       └─TableFullScan_18           | 524288.00  | mpp[tiflash] | table:a       | pushed down filter:empty, keep order:false         |
+------------------------------------+------------+--------------+---------------+----------------------------------------------------+
11 rows in set (0.00 sec)

ExchangeSender_32 and ExchangeSender_20 are actually two standalone mpp sub-queries, and each of the subqueries in TiDB side is handled by a mpp_gather, so this query will generate mpp tasks that belongs two different mpp_gather. From tidb's point of view, different mpp_gather has its own lifecycle, it is possible that TiDB wants to cancel one of the mpp_gather's execution while keep other mpp_gather's execution un-affected. For example, if Limit_25 has enough input, TiDB will cancel the mpp_gather that opens ExchangeSender_32, and of cause, TiDB does not want ExchangeSender_20 to be affected by that cancel(After #7589, it almost 100% sure that ExchangeSender_20 will be affected by that cancel). This means when TiDB send a CancelMPPQuery request, it actually wants to cancel all the mpp tasks that belongs to a specific mpp_gather. After pingcap/tidb#44697, TiDB already set a meaningfull value of gather_id in mpp::TaskMeta, it's time for TiFlash to support MPPGather' level's cancel