feat(tx-cache): Pagination types and client impl

[Evalir]

Adds cursor-based pagination types to the tx-cache crate. This allows us to implement pagination on the cache, and for the tx-cache client to be able to use pagination queries.

Getting all items in one of the collections in the cache is as simple as:

• getting items in the collection, which will return a PaginationInfo
• passing the cursor returned from PaginationInfo into the next request. This can easily be done by .into()ing a PaginationInfo into a PaginationParams.
• do this repeatedly until there are no more pages. PaginationInfo has an utility method to detect this.

These changes are not breaking for the current tx cache consumers.

[Evalir]

• feat(tx-cache): Pagination types and client impl #131 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[rswanson]

is this a breaking change for existing consumers of the api? i.e. if they are using an older version of the builder will their builder break if I deploy this version of the tx cache?

[Evalir]

Not technically a breaking change. The builder will still be able to fetch items from the cache as serde can partially deserialize JSON (it's a self-described format). They will be missing the pagination info, which is fine for now. I've added partial deser tests on the companion pagination PR to confirm this.

[prestwich]

these changes are currently breaking, as serde will expect pagination info to be present unless given a specific serde(default) or similar attribute tag

[prestwich]

I would prefer to see something like:

pub enum CacheResponse<T> { 
    Paginated{
        inner: T,
        pagination: PaginationInfo
    },
    Unpaginated(T),
}

[Evalir]

took a stab at the suggestion @prestwich, wdyt?

[prestwich]

add serde roundtrip tests with what you think these json objects should look like.

If pagination params is a query, I don't think it's appropriate to use serde. Instead, there should be a method to apply it to a url?

[prestwich]

why does this struct exist now?