Use plan ID to filter namespace eligibility for purchase

What does this MR do?

Addresses part of: #326663 (closed)

This is a follow up to the corresponding MR in the customers application: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3602

Currently, the CI minutes purchase flow re-uses the eligibility criteria for making a new license purchase. This is filtering out namespaces that have a Premium/Ultimate subscription as they are not eligible for a new license subscription, but they are still eligible to purchase new CI minute packs.

This MR updates the subscriptions controller to fetch the CI minutes plan ID and then supply that to the eligibility criteria API.

Note: currently there is a duplicated call on the frontend to fetch the CI minutes plan ID. I will raise a follow up issue to supply this information directly from the backend, rather than making the call twice.

📸 Screenshots or Screencasts

SCENARIO	BEFORE	AFTER
Group without any subscriptions	BEFORE-no_subscription	AFTER-no_subscription
Group with active license subscription	BEFORE-with_subscription	AFTER-with_subscription
Group with active CI minute subscription	BEFORE-with_ci_minutes	AFTER-with_ci_mintes

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
  • This is mostly a refactor, and the rest is behind a feature flag so I don't think this warrants a changelog
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Security

Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.

• ~~Label as security and @ mention @gitlab-com/gl-security/appsec~~
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team