Issue

The performance of the /v3/service_plans in foundations with large numbers of organizations (and thus large numbers of service plan visibilities) is significantly slower than the /v2/service_plans endpoint

Context

(This is a continuation of parts of #1591, using the numbers in this comment)
For a large CF deployment with many orgs and brokers, the /v3/service_plans endpoint is up to 25x slower than the /v2/service_plans endpoint. This means that for a user using the CLI v6, cf marketplace takes ~4 seconds but a CLI v7 (thus /v3 user) cf marketplace takes ~90 seconds.

Steps to Reproduce

• Seed the DB with the orgs, spaces, service brokers, services, service plans and service visibility numbers from this comment
• Run cf curl /v2/service_plans and time it
• Run cf curl /v3/service_plans and time it
• (Bonus) Run cf curl /v2/service_plans?per_page=500 and time it
• (Bonus) Run cf curl /v3/service_plans?per_page=500 and time it

Expected result

/v3 timings are at least comparable to /v2 timings
/v3 timings should not increase significantly when querying more results per page (/v2 timings don't)

Current result

/v3 timings are 10-100x slower than /v2
/v3 timings scale roughly linearly with per_page size

Possible Fix

We've done a lot of investigation into this, full context will be in a PR to follow. The basic explanation is that the service plan visibilities table is so large since it is ~ NUM_ORGS * NUM_SERVICE_PLANS that eagerly fetching results from it is extremely slow