Before this fix, the performance schema would use a lot of CPU
to execute PFS_table aggregate functions in general.

With this fix, execution has been improved, per the following changes:

1)

In PFS_table::aggregate(),
the code used to call safe_aggregate() if any stat was present.

When both m_has_io_stats and m_has_lock_stats are true, this is correct.

When only m_has_io_stats or m_has_lock_stats is true, this is overkill.
Calling safe_aggregate_io() or safe_aggregate_lock() is better in this case.

2)

Likewise for PFS_table::sanitized_aggregate()

3)

In PFS_table_stat::aggregate_io() and PFS_table_stat::sum_io(),
the code did loop on every possible index in the [0, MAX_INDEXES-1] range,
regardless on whether the table actually had that many index used.

Now the code only use index statistics for index that do exist,
using the [0, key_count] range.

Calling code has been adjusted accordingly.

4)

For a given index statistic, PFS_table_io_stat::m_has_data was added.

This boolean indicates of data has been collected for this index.

Using this flag saves a lot, because even if a table can effectively have
many indexes, a thread opening the table, performing a select, and closing
the table is more likely to use one index only (or a few), instead of all the indexes
available.

When aggregating the statistics for this thread to the table statistics,
testing this flag saves on CPU.

5)

For code clarity only (no performance change),
MAX_KEY has been replaced by MAX_INDEXES, which is more accurate.
These two constants are synonym.