Make table cache mutex contention threshold configurable

Currently there is a check for lock table cache mutex contention that considers an instance to be contested if more than 20000 mutex acquisitions cannot be immediately serviced before 80000 are immediately serviced. The comments in the code indicate that this is because of the estimated 100K queries per second is the maximum. These values are hard coded based on 2 socket / 20 core / 40 thread Intel Broadwell systems with a comment that these numbers may need to be adjusted for other systems. Broadwell was released in 2015 so these numbers are likely very dated.

In our scalability testing we found the table cache mutex contention at 20% sometimes took a couple of tests to get to a steady state. Before then the performance was lower. This could mean when doing benchmarks that people may see an artificially lower number on initial tests than after waiting for a couple of runs. When we set this hard-coded value to 10K misses before 90k hits, our systems ramp up to the setting chosen for the number of table_open_cache_instances more quickly, removing this bottleneck in the first test.

We suggest making this value configurable so it can be adjusted for the system being used.