Reduce the impact of not using fail points

[Algunenano]

Changelog category (leave one):

• Performance Improvement

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Reduce the impact of not using fail points

selectPartsToRead is a really common function to do index analysis and checking for failpoints is expensive as it requires a function call and a global lock (see #88184). This PR removes the slowdown_index_analysis failpoint while trying to keep the associated test running correctly (let's see the CI).

It also introduces a fast path for the most common case which is not using fail points at all (they should only be used in CI) by having a global atomic variable that checks whether any fail point has been enabled or not. If it hasn't, then it avoids the path.

Requires ClickHouse/libfiu#4

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

[clickhouse-gh]

Workflow [PR], commit [a3c0f11]

[rschu1ze]

Re the fastpath that uses atomics: I am not again it but tbh, the more robust solution would be to force-disable failpoints via CMake in release builds (but not 100% sure if anyone ever used failpoints in a prod/customer build).

[Algunenano]

Re the fastpath that uses atomics: I am not again it but tbh, the more robust solution would be to force-disable failpoints via CMake in release builds (but not 100% sure if anyone ever used failpoints in a prod/customer build).

We do, for CI only. For example the test that I'm modifying is enabled only for release build. We can try this way and if it's a problem again think about keeping failpoints only for debug and sanitizer builds, but that will require reviewing all tests.