Fix CNH default pod replica counts for smaller environments

What does this MR do?

MR fixes an issue with Cloud Native Hybrid pod count and sizing calculations for smaller environments.

Calculations are still pinned on Gitaly CPU but since there's not a linear equivalent we now use a direct map to translate Gitaly CPU count into the correct pod counts. MR also fixes an incorrect scale down of worker pods from 4 to 2 workers on 3k/5k environments which should only be getting applied to 2k envs.

For environments that don't directly map we'll fallback to a best effort failsafe of calculating reasonable values based on Gitaly CPUs as follows:

• Webservice - Divide Gitaly CPUs by 2.4. This is what we had currently and is generally the closest linear value we have across the Reference Architectures as a best effort.
• Sidekiq - Since it's not so linear here we default to 14 pods for 10k+, 8 pods for 3k/5k and 2 pods for 2k.

As always users can override pod counts at any time.

Related issues

Closes #498 (closed)

Author's checklist

When ready for review, the Author applies the workflowready for review label and mention @gl-quality/get-maintainers:

• Merge request:
  • Corresponding Issue raised and reviewed by the GET maintainers team.
  • Merge Request Title and Description are up-to-date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline
  • MR has no new security alerts in the widget from the Secret Detection and IaC Scan (SAST) jobs.
• Code:
  • Check the area changed works as expected. Consider testing it in different environment sizes (1k,3k,10k,etc.).
  • Documentation created/updated in the same MR.
  • If this MR adds an optional configuration - check that all permutations continue to work.
  • For Terraform changes: set up a previous version environment, then run a terraform plan with your new changes and ensure nothing will be destroyed. If anything will be destroyed and this can't be avoided please add a comment to the current MR.
• Create any follow-up issue(s) to support the new feature across other supported cloud providers or advanced configurations. Create 1 issue for each provider/configuration. Contact the Quality Enablement team if unsure.