Summary
Implement a new endpoint to return the list of billing_account_ids for all instances currently reporting under a specified org_id and optional product_tag/billing_provider

Background

If you load the instance list in the UI, we put instances for all cloud accounts together, which isn't super useful for a user. The UI will be updated to default to filter to a particular billing account id. Cloud accounts where they have usage coming in, and a second API where they have cloud accounts for subs with a given product. Then be able to say "this account you're sending for doesn't have an active subscription"

Acceptance Criteria

Endpoint Details:
New GET endpoint at /api/swatch-tally/v1/instances/billing_account_ids

Required Parameters:
org_id, string, query parameter, can support only one value

Optional Parameters:
product_tag, string, query parameter
billing_provider, string, query parameter

Paging:

This API should be paginated in the same manner as the instances API.

No paging, because we expect this to be used to populate a drop-down.

Sorting:
Apply basic alphabetical sorting by default so it's easier for users to find what they're looking for in the drop down menu.

SORT BY billingProvider, billingAccountId ASC

Headers:
x-rh-identity

Authorization:
RH Associates w/ admin permission: If the user is an RH associate w/ admin privileges, the org_id in the header does not need to match the org_id in the query parameters.

Customers: If the user is a customer, the org_id in the header must match the org_id in the query parameters. If it does not, return a 403 Unauthorized response.

Response:
200 OK: Returns an array of objects with fields:

• org_id
• product_tag
• billing_provider
• billing_account_id

If no billing account IDs match the specified filters, return an empty array.

Configuration:
Add an entry to the nginx reverse proxy configuration in the swatch-api to direct requests to /api/rhsm-subscriptions/v1/instances/billing_account_ids to /api/swatch-tally/v1/instances/billing_account_ids

Performance Consideration:
Consider which "starting point" (e.g. host_tally_buckets, tally_snapshots) will have the lowest cardinality of data loaded into memory
-Refinement note: host_tally_buckets has many fewer rows than tally_snapshots and likely a better option.

Scenarios to test:

• When an unauthenticated user attempts to access this endpoint they get a 401 Unauthorized response
• When a RH associate without admin permissions accesses this endpoint, they get a 403
• When a RH associate with admin permissions accesses this endpoint, they are able to provide any org_id and get a 200 OK.
• When a customer accesses this endpoint and specifies their own org_id, they get a 200 OK.
• When a customer accesses this endpoint and specifies a different org_id, they get a 403.
• Any authenticated attempt to access this endpoint with a missing org_id returns a 400.
• Given an account without any billing_account_ids, the response from an authenticated customer should be a 200 OK with an empty array.
• Given an account without more than one page of billing_account_ids, the response from an authenticated user customer should be a 200 OK with paginated results.
• When an authenticated request attempts to pass more than one org_id, there should be a error response (exact code/error is dependent on resteasy/jax-rs behavior)