Increase default max_suspicious_broken_parts to 100

[stevenobird]

Increase the max_suspicious_broken_parts setting to adapt to more modern setups

Depending on the environment where self-hosted Sentry is running on, it could happen more than often enough that Clickhouse reports errors like this:

Application: DB::Exception: Suspiciously many (12 parts, 0.00 B in total) broken parts to remove while maximum allowed broken parts count is 10. You can change the maximum value with merge tree setting 'max_suspicious_broken_parts' in <merge_tree> configuration section or in table settings in .sql file (don't forget to return setting back to default value):

In some cases, the Clickhouse container refuses to restart until that setting is changed in clickhouse/config.xml.

A prior PR where the default setting of 10 was introduced even mentioned the new Clickhouse default of 100, but 10 was submitted, most likely to not break current installations.

In reality, this setting will only be effective when Clickhouse is shut down improperly and tries to recover data at restart. In those cases, users should either have backups to circumvent Clickhouse's self-recovery completely or let it do its job, but with a higher threshold (the de-facto default of 100 since 2022).

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[aldy505]

Why not?