Set default limit on /access/ to max limit when no pagination limit supplied

[coderbydesign]

In a recent PR we removed the default limit on the /access/ endpoint, to ensure all
records were returned in a single request instead of using the default of 10.

This meant in order to be backwards compatible, we'd also need to continue supporting
pagination params. To do this, we updated the spec to include oneOf two possible
valid responses, one paginated and one unpaginated. The data would remain the
same, but the meta data for pagination would not be included unless a limit
param was supplied in the request.

The associated updates were made to the openapi.json spec, but due to an existing
bug/issue in the OpenAPI Generator project [1,2], this breaks some client generation
which is used by app teams and QE, even though it's valid per the spec.

In order to avoid having a separate endpoint explicitly for a paginated responses,
and to also avoid constructing false meta data for pagination, we've decided to
set the default limit on the /access/ endpoint equal to the max limit number
when no limit is supplied, but continue to respect the limit pagination param
when it is supplied.

This will allow for client generation to continue to work, and will allow those
using pagination by default to still be supported. For those not using pagination,
the response data should again still be the same, and the default limit will not
be a barrier to hitting pagination, as it will be the same as our max results.

[1] OpenAPITools/openapi-generator#15
[2] OpenAPITools/openapi-generator#1709

[wcmitchell]

LGTM!