[ENH]: Further optimize query on getCollections when databases pkey is fully specified (#5268)

## Description of changes

An earlier [change](https://github.com/chroma-core/chroma/commit/9a54b8bb1ca576afd3367f22a81171c4a4a563ab) attempted to optimize the sysdb query in the case where the primary key for databases was fully specified. This was incomplete as it created a filtered subquery with a LIMIT + OFFSET inside the subquery. This would prevent the filter from being pushed down into the subquery during optimization. This change also sets the GUC `random_page_cost=1.1` for that query to be more in line with practices of SSD-based database instances. We conservatively only touch that GUC for this GetCollections change but we should look into assessing doing this database-wide.

- Improvements & Bug fixes
  - ...
- New functionality
  - ...

## Test plan

_How are these changes tested?_

- [ ] Tests pass locally with `pytest` for python, `yarn test` for js, `cargo test` for rust
Locally benchmarked this on a database with 10k collections. The benchmark that just repeatedly does `list_collections` improves from ~100 rps to 400 rps.

The p99 latency for this benchmark goes from ~22ms to ~5ms.

## Migration plan

_Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?_

## Observability plan

_What is the plan to instrument and monitor this change?_

## Documentation Changes

_Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the [docs section](https://github.com/chroma-core/chroma/tree/main/docs/docs.trychroma.com)?_