Limit size of param and request/response arrays

[lidel]

This PR

• adds PinResults object
  • PinResults.count indicates the size of total number of results for pagination (closes #12 as per feedback in https://github.com/ipfs/pinning-services-api-spec/issues/12#issuecomment-656425010)
  • Makes it easier to set hard limits on the number of responses for a single query
• adds explicit limits on filter results (cid and status), as per feedback in https://github.com/ipfs/pinning-services-api-spec/issues/15#issuecomment-656742892 and closes #15

Docs preview for this PR: https://bafybeid6e52x5oyeeefa27r3yszp7r64j6i4tekznjkoqvc4tw3qh3sxry.ipfs.dweb.link/

---

@obo20 this change adds hard limit to all arrays (params and in /pins request/response):

maxItems: 1000

Let us know if this is ok or should be adjusted (we'd like to keep the same limit everywhere, for simplicity)

[jacobheun]

This looks good for results, however, I don't think https://github.com/ipfs/pinning-services-api-spec/issues/15#issuecomment-656742892 was addressed. IIUC this is requesting to also limit the number of cids in the query param. Right now there's nothing explicitly stating I can't just pass in 10k cids. I'll only get 1k max results back.

We should limit what we allow there for performance and possible server query param length collision issues.

[lidel]

@jacobheun I believe maxItems in the definition of cid array parameter guards us against the scenario described in https://github.com/ipfs/pinning-services-api-spec/issues/15#issuecomment-656742892:

https://github.com/ipfs/pinning-services-api-spec/blob/2cacfb1ffdd461d4412d780fe6497cdb2805087e/ipfs-pinning-service.yaml#L313-L324

GET /pins?cid=.. with more than 1000 CIDs will be rejected.

If I misread your comment, let me know!