chore: Refactors fail_index_key_too_long to be compatible with old implementation and use zero values in advanced_configuration

[EspenAlbert]

Description

Refactors fail_index_key_too_long to be compatible with old implementation and use zero values in advanced_configuration

Link to any related issue(s): CLOUDP-287995

Type of change:

• Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
• New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
• Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
• This change requires a documentation update
• Documentation fix/enhancement

Required Checklist:

• I have signed the MongoDB CLA
• I have read the contributing guides
• I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
• I have added any necessary documentation (if appropriate)
• I have run make fmt and formatted my code
• If changes include deprecations or removals I have added appropriate changelog entries.
• If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

[AgustinBettati]

q: If FailIndexKeyTooLong is not defined in API response because an old mongodb version is used, wouldnt we want the user to be aware that this property was not set? How does this scenario work in SDK v2?

[EspenAlbert]

In SDK v2 we use the Getter methods:
"fail_index_key_too_long": p20240530.GetFailIndexKeyTooLong(),
So even when the API returns null it will still be set to false