Before this fix, a statement received from a client was instrumented as
follows:

When a new packet is detected at the socket level,
a new statement is started, with a temporary name "statement/com"

Then the packet number is read, so the server knows what type of command the
request is.
The statement name is then refined to for example "statement/com/Query".

The query text is read and given to the parser.
After parsing, the exact type of SQL statement is known.
The statement name is then refined to for example "statement/sql/insert",
which is now a final event name.

The problem with this approach, is that instrument names like:
- "statement/com"
- "statement/com/Query"
are used for special purposes, but this is not obvious.

To collect statistics only for INSERT statements for example,
enabling the "statement/sql/insert" instrument is not sufficient,
the "statement/com" and "statement/com/Query" instruments must be enabled as
well.

Also, for instruments such as "statement/com", no statistics are even
aggregated for this type of statement, because no real statement is ever
classified with "statement/com" as a final name.

The same issue exists with statements read from the relay log on a slave.

With this fix,

1)

Every instrument name in performance_schema.setup_instrument
that corresponds to abstract statements have been renamed, for clarity.

"statement/com/" is renamed to "statement/abstract/new_packet"
"statement/com/Query" is renamed to "statement/abstract/Query"
"statement/rpl/relay_log" is renamed to "statement/abstract/relay_log"

2)

Statistics for abstract statements are no longer displayed in
the following tables:
- events_statements_summary_by_thread_by_event_name
- events_statements_summary_by_account_by_event_name
- events_statements_summary_by_user_by_event_name
- events_statements_summary_by_host_by_event_name
- events_statements_summary_global_by_event_name