IORateLimiter's auto tune strategy is not optimal

Enhancement

Reproduce steps

1. load chbenchmark 1500 into a cluster with tiflash
2. set the io rate limiter with config as follow

[storage]
[storage.io_rate_limit]
background_read_weight = 0
background_write_weight = 20
foreground_read_weight = 0
foreground_write_weight = 80
max_bytes_per_sec = 209715200

3. run the chbenchmark tp with 100 concurrency

tiup bench ch --host 10.2.12.81 -P 8080 --warehouses 1500 run -D chbenchmark -T 100 -t 0 --time 30m

foreground write and background write

We can see that bg_write alloc bytes is much more than fg_write alloc bytes. The current auto tune logic tends to tune more write_bytes limit for bg jobs rather than fg jobs. Thus causing fg write pending. This is not as expected.
When the total bytes per seconds almost reach the limit, we should first ensure the requirements for fg jobs rather than bg jobs.

Read alloc mismatch with read request

As shown in the below figure 1 and figure 2, whether it is foreground reading or background reading, "read alloc" is always much smaller than "read req". This may be caused by the file system's PageCache.
However, as shown in figure 3, it still cause unexpected rate limit on the fg read or bg read, though the disk throughput is still free.

Sub-taks:

• https://github.com/pingcap/tiflash/issues/10247

Start with the IORateLimiter auto-tune logic and reproduce the behavior using the provided TiFlash configuration and chbenchmark command. Compare foreground and background read/write allocation with request rates and disk throughput; done means foreground work is prioritized near the total limit and available disk capacity is not unexpectedly throttled.