Change how page, find, and list work together

[Brian Curtin]

[this is a metaissue to track a few interrelated changes]

We're trying to solve a few different problems at once, but there are two above all that we need to solve: `find` by default has to find an item if it exists regardless of how much data it consumes, and `list` has to work for both paginated and nonpaginated repsonses. There are five reviews out in these areas and they all go about things slightly differently each changing how the others can work.

find
====

`find` is at the root of this because it currently consumes `page`. However, for `find` to work properly as a base implementation, it really has to use `list`. It can do other things to make it consume less data where possible, and there's a change to enable this, but by only finding within one page we guarantee there are possibilities where we won't return something that exists when it's on another page. With the current implementation, we guarantee we won't return something on a resource that uses different filter names.

page
====

Since `find` has to use `list`, `page` is really just an intermediary to serve pages directly to `list`. In that capacity, it should either return a response body to `list` so it can create objects, or it should do the object creation itself and return a generator, but it shouldn't create a temporary list since that will be thrown away. If we create a list and then turn it into a generator, we lose the benefit of it being a generator.

list
====

In order for `list` to work properly both by itself and as a producer for `find`, it has to support both paginated and nonpaginated bodies. This is a general issue that we've needed to solve, but it has consequences if it also cases `find` to enter an infinite loop.

Since we have changes that can't all work together, I think we should try to solve these problems in the following order.

1. Fix `find` to use `list` but enable URL query parameter filters to be passed in, to be used like the ones we have hardcoded
1a. At this point `find` will be broken for nonpaginated searches.
2. Fix `list` to work with both types of bodies. At this point the only fail-safe way is a parameter, and it also allows flexibility during enabled/disabled cases.
2a. At this point `find` will work for all.
3. Fix `page` to do what it needs to do to serve `list` the best. Additionally, since it only lives to serve `list`, we should possibly explore making it private since it's an implementation detail.

If we do it this way, we're only modifying the behavior of one method at a time.

[Brian Curtin (brian.curtin)]

We've changed what we're looking for out of some of this, so this approach isn't all that valid anymore, especially not as a big meta-issue. Anything smaller that we need to fix can be done on its own.