Fix: don't set deprecated registry threshold when maxretries is configured

What does this MR do?

Fixes a bug where Omnibus GitLab automatically injects the deprecated threshold parameter into registry notification endpoint configuration even when users have already migrated to the new maxretries parameter.

The root cause is in parse_registry_notifications in files/gitlab-cookbooks/gitlab/libraries/registry.rb:

endpoint['threshold'] ||= user_configuration['default_notifications_threshold']

This line unconditionally sets threshold from the default value (5) regardless of whether maxretries is already configured on the endpoint. The fix adds a guard so that threshold is only set from defaults when maxretries is not already present on the endpoint.

Before: Configuring maxretries: 5 on a notification endpoint would still result in threshold: 5 being injected into the generated config.yml, triggering deprecation warnings.

After: When maxretries is set on an endpoint, threshold is not automatically added, so users who have migrated to the new parameter no longer see spurious deprecation warnings.

Related issues

Closes #9321 (closed)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• MR title and description are up to date, accurate, and descriptive.
• MR targeting the appropriate branch.
• Latest Merge Result pipeline is green.
• When ready for review, MR is labeled workflowready for review per the Distribution MR workflow.
• The UBT version and corresponding checksum hash have been updated and referenced in the merge request if applicable.
  • UBT EE pipeline (Trigger:ee-package-ubt) is green

For GitLab team members

If you don't have access to this, the reviewer should trigger these jobs for you during the review process.

• The manual Trigger:ee-package jobs have a green pipeline running against latest commit.
  • To debug QA failures, refer to the Investigate QA failures section.
• If config/software or config/patches directories are changed, make sure the build-package-on-all-os job within the Trigger:ee-package downstream pipeline succeeded.
• If you are changing anything SSL related, then the Trigger:package:fips manual job within the Trigger:ee-package downstream pipeline must succeed.
• If CI configuration is changed, the branch must be pushed to dev.gitlab.org to confirm regular branch builds aren't broken.

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes.
• Documentation created/updated. N/A — this is a bug fix with no user-facing configuration changes.
• Tests added. A new RSpec context covers the case where maxretries is set and threshold must not appear in the generated config.
• Integration tests added to GitLab QA.
• Equivalent MR/issue for the GitLab Chart opened.
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme[REDACTED]host:port may require quotation or other special handling when rendered in a template and written to a configuration file.