[receiver/mysql]: add scraping io_waits metrics

[aboguszewski-sumo]

Description:
This PR adds scraping metrics related to I/O waits for tables and indices. There are 4 new metrics. List of used attributes was taken from here: https://github.com/influxdata/telegraf/tree/master/plugins/inputs/mysql#tags

Link to tracking Issue:
#14138

Testing:
Unit tests for scraper and integration tests have been updated. The integration tests required putting some example data (empty schema, table and index), which is done in the setup.sh script.

Documentation:
Documentation automatically generated by mdatagen.

[djaglowski]

Looks pretty good. A couple minor points to address though.

[djaglowski]

Presumably the extra whitespace is ignored by the database, but is it worth building the string in such a way where it is nicely formatted. I imagine users who see the query in the database's query log may find this format unusual.

[aboguszewski-sumo]

I changed it a bit:

SELECT OBJECT_SCHEMA, OBJECT_NAME, COUNT_DELETE, COUNT_FETCH, COUNT_INSERT, COUNT_UPDATE,
	SUM_TIMER_DELETE, SUM_TIMER_FETCH, SUM_TIMER_INSERT, SUM_TIMER_UPDATE
FROM performance_schema.table_io_waits_summary_by_table
WHERE OBJECT_SCHEMA NOT IN ('mysql', 'performance_schema');

[djaglowski]

This still seems odd to me. It reads nicely in code, but why should it contain return chars and tabs that are useful only for the golang code? How about something like this:

query := "SELECT OBJECT_SCHEMA, OBJECT_NAME, COUNT_DELETE, COUNT_FETCH, COUNT_INSERT, " +
	"COUNT_UPDATE, SUM_TIMER_DELETE, SUM_TIMER_FETCH, SUM_TIMER_INSERT, SUM_TIMER_UPDATE " +
	"FROM performance_schema.table_io_waits_summary_by_table " +
	"WHERE OBJECT_SCHEMA NOT IN ('mysql', 'performance_schema');"

It's simple and reads clearly in both go and sql domains.

[djaglowski]

Same here

[aboguszewski-sumo]

Changes applied.

[aboguszewski-sumo]

A small update regarding the time metrics:
I tried to verify the unit of this metric. It turns out that it's stored in the database in picoseconds (10^-12 of a second, it was hard to find because the documentation was not clear, but I finally found this in MySQL source code). Hence, we need to convert this result to some other unit.
In my opinion, milliseconds sound reasonable, so I'm converting this into milliseconds. Let me know if some other unit would be better.

[djaglowski]

It turns out that it's stored in the database in picoseconds...
Hence, we need to convert this result to some other unit. In my opinion, milliseconds sound reasonable, so I'm converting this into milliseconds. Let me know if some other unit would be better.

I agree with not using picoseconds. My suggestion would be to use nanoseconds and to represent it as an int (var ns int64 = picos/1000), rather than fractional unit. Technically, we are dropping a tiny amount of precision, but I am skeptical that it is meaningful in any context, or even accurate to that level.

[djaglowski]

Thanks for iterating @aboguszewski-sumo