Tracing Feature for MySQL requests

Please provide a way to trace MySQL requests, having particular attributes.

For example, if a request is marked as belonging to a group N, trace 1% of such requests.

Reference:

https://dev.mysql.com/doc/refman/8.0/en/query-attributes.html

https://dev.mysql.com/doc/extending-mysql/8.0/en/writing-audit-plugins.html

https://www.percona.com/doc/percona-server/LATEST/management/audit_log_plugin.html

https://dev.mysql.com/worklog/task/?id=12542

https://github.com/percona/percona-server/commit/6b422727fbae99a332c8f548d5ba865207674e04

https://github.com/percona/percona-server/commit/7cb230c992402804118b116a1c8038bb82240514

https://github.com/percona/percona-server/commit/e1b5f812a14565de60249d717f810d982244cd4d

 -----

Proposal:

As of 8.0.23, MySQL now has the concept of Query Attributes.  This extends the client, the server, and the client-server protocol.  In the MySQL Community Edition, the functionality is basically a road to nowhere.  Queries come in, get parsed, attributes get associated with the query, etc..., but the information is not presented anywhere where a user application can can consume this.  The worklog and code shows that this information can be accessed from within the server via a new component API.  This means that this information should be accessible by some Percona extension and presented in some way, such as an extension to Audit Log Plugin and the records it produces.  It does not yet appear that the MySQL Enterprise Audit Plugin has added any additional functionality to expose this additional data.  Based on the worklog and the implementation, we should be able to iterate the attributes of each query and extend the Audit Log records to include some new fields such as:

"ATTRIBUTES"="<number_of_attributes>"

"ATTRIBUTE_1"="<parsed_attribute>"

"ATTRIBUTE_2"="<parsed_attribute>"

"ATTRIBUTE_3"="<parsed_attribute>"

etc...

This new information will be available with the addition of a new enumeration value for audit_log_policy of QUERIES_ATTRIBUTES that would enable the addition of the query attribute information within the log records so legacy users could continue with just QUERIES behavior and not have to worry about adjusting their parsers.

Filtering should follow the existing model for commands, two new variables will be introduced, audit_log_include_attributes and audit_log_exclude_attributes that will behave similar to audit_log_include|exclude_commands.