Allow configuring thresholds for Database Integrity Checks (Select_full_join / Created_tmp_disk_tables) #66129

Is your feature request related to a problem? Please describe.
The current database integrity checks (under "Administration settings" -> "Overview") use hardcoded thresholds (e.g., triggering a "Failing" status when Select_full_join > 1% or Created_tmp_disk_tables is high). See output:

Performance 1 failing
Joins without indexes
Warning ·Select_full_join
Failing
Some joins are scanning entire tables because no usable index exists on the join column.
0.9211% of queries did a full join without an index.
Identify the offending queries (set log_queries_not_using_indexes) and add the missing indexes.
Value 0.92

Memory 1 failing
On-disk temp tables
Warning ·Created_tmp_disk_tables
Failing
A large share of temporary tables are being created on disk instead of in memory.
45.9599% of temp tables ended up on disk.
Increase tmp_table_size and max_heap_table_size to keep more temp tables in memory.
Value 45.96
Adjustment tmp_table_size→64M
Show config snippet

For small to medium instances with moderate traffic, these hardcoded percentages are statistically skewed. A very small number of "imperfect" but harmless queries (like information_schema lookups) triggers false-positive "Failing" warnings. This creates "warning fatigue" for system administrators, as these warnings do not correlate with actual performance bottlenecks or slow queries.

Describe the solution you'd like
I propose adding configuration options in config.php to customize these thresholds. For example:
'database.integrity.check.full_join_threshold' => 5.0, // Allow up to 5%
'database.integrity.check.tmp_disk_threshold' => 20.0, // Allow up to 20%
Alternatively, allow us to disable specific database performance warnings in config.php if the administrator has verified the database performance via logs (e.g., using percona-toolkit).

Describe alternatives you've considered
Currently, the only way to clear these warnings is to restart the database service to reset the GLOBAL STATUS counters. This is a workaround, not a solution, and doesn't represent the true health of the database.

Additional context
My system basics:
Nextcloud Server version: 35.0.2
Operating system and version: Ubuntu 24.04
Web server and version: nginx/1.24.0
Reverse proxy and version: none
PHP version: 8.4.27
I have verified my database performance using slow query logs and EXPLAIN analysis.
My queries are optimized, but the nature of Nextcloud's schema (many small tables, JSON columns) makes it statistically impossible to keep these counters below the current hardcoded thresholds in a small-volume production environment.
This happened after upgrading to the last version of Nextcloud.
Output command: EXPLAIN SELECT appid, configkey, configvalue, type FROM oc_appconfig WHERE lazy = 0;
+------+-------------+--------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+--------------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | oc_appconfig | ALL | ac_lazy_i | NULL | NULL | NULL | 229 | Using where |
+------+-------------+--------------+------+---------------+------+---------+------+------+-------------+