Avoid reading `plan` field from the statements summary and the slow query system table

[time-and-fate]

Feature Request

Is your feature request related to a problem? Please describe:

In one oncall ticket, the tidb node has a very high memory usage when the user is visiting the SQL Statements Details page. And it turns out it's caused by the DecodePlan() function.

DecodePlan() will be called when a query tries to access the plan field of the *statements_summary* and *slow_query tables.

Sometimes, the user accesses a details page of a SQL with lots of execution plans. Occasionally, there are some large execution plans.
What's worse, we find the ability of MemTablePredicateExtractor in tidb is limited. It would only filter the entries by SQL digest before doing the DecodePlan(), the time window and the plan digest filters will be applied after DecodePlan() is finished.
That means if you query a 30-minute time window in the SQL Statements page, and open the detail page for a SQL with 3 execution plans, there will be 3 * 24 = 72 DecodePlan() happen even if only one execution plan will be displayed at first. (By default, there will be 24 time windows)

Describe the feature you'd like:

From LTS v6.5, the binary_plan has been available from tidb, and the dashboard has been relying on the binary_plan to provide a more readable execution plan text, and also the visual plan feature.

Essentially, the dashboard no longer needs to access the plan field anymore.
Optimizing the performance in tidb probably takes a long time, but not reading the plan from the dashboard should be able to quickly solve the problem.

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy: