Before this fix, the server variable 'max_digest_size'
was used in two places.

1)

During query parsing, the server collects the statement digest text,
and store the digest in a buffer of size 'max_digest_size'.

Only 1 digest text per session is needed at the same time,
which limits the memory consumption.

2)

In the performance schema, the digests collected in 1) are
copied in various tables, and the memory allocated to
keep digest historical or aggregated data also depends on 'max_digest_size'.

Many digests text per session are preserved at the same time,
so that the total memory consumption is a multiple of 'max_digest_size',
making this parameter sensitive.

The problem is that for some deployments,
namely when using either the firewall plugin or the query rewrite plugin,
DBA typically need to have at the same time:
- a big value for 1), to avoid truncation
- a lower value for 2), to limit memory consumption,
  even if truncations can occur in the recorded performance schema data.

The solution is to keep variable 'max_digest_size' for part 1),
and create a separate variable 'performance_schema_max_digest_size' for part
2), so that sizing for the firewall/query rewrite can be independent of the
performance schema.