separate arbiter and members resource creation

[sina-grz]

Summary

I previously described the problems and possible solutions in this issue:
#416
mongodb/mongodb-kubernetes-operator#1737

This branch implements the second proposed solution: Context-Aware Default Templates.
The goal is to avoid unnecessary resource waste by providing separate defaults for arbiters vs. data members while keeping customization consistent.

Proof of Work

Implementation:

• Pass an isArbiter boolean to the build function
• Apply arbiter-optimized defaults when isArbiter=true:
  • No PVC
  • Minimal resources
• Maintain current behavior for data members
• Keep spec.statefulSet for member customization only

Checklist

• Have you linked a jira ticket and/or is the ticket in the title?
• Have you checked whether your jira ticket required DOCSP changes?
• [ ✅] Have you added changelog file?
  • use skip-changelog label if not needed
  • refer to Changelog files and Release Notes section in CONTRIBUTING.md for more details

[vinilage]

Thank you very much @sina-grz for the contribution. We will review the PR and get back to you.

[codeowners-service-app]

Assigned Julien-Ben for team kubernetes-hosted because fealebenpae is out of office.
Assigned viveksinghggits for team kubernetes-hosted because lucian-tosa is out of office.

[PeterC89]

IMO it would be nice if it were possible to define a separate spec for arbiters.
For example, we have a need to run an arbiter on a specific node, which can't be done under the current setup, or via the option proposed in this PR.
Sadly it's not a feature I can contribute to as I'm not a Go developer 😢

[vinilage]

Hi @sina-grz,

Thanks again for taking the time to open this PR and for your interest in MongoDB Controllers for Kubernetes, we really appreciate the contribution.

At this time, we won’t be able to move forward with this change. MCK is used by many customers in production, and we follow a strict internal development and review process to ensure alignment with our roadmap, quality, and security requirements. As a result, we’re currently limiting merged changes to those driven through that process rather than standalone enhancements.

That said, we value community feedback. If this PR reflects a broader use case, we’d be happy to discuss it further in an issue to better understand the need.

Thanks again for your understanding.