Building the user manual was hitting a problem when trying to

serialize links for the DraftFileAttachmentResource, where it wasn't

finding the right review request.
After a trip far down the rabbit hole, I narrowed this down to a bug in

djblets.webapi.resources.base.WebAPIResource.get_object, and the caching

that it does. This method attempts to keep a cache of objects, which is

stored on the request object. Unfortunately, the cache key computation

is broken for resources which are singleton but are children of

non-singleton resources. In this case, ReviewRequestDraftResource is

marked as singleton, but its parent resource is not singleton. We really

ought to be chaining up the tree of resources and letting each one

contribute to the cache key.
Because changing the cache behavior in djblets is very risky right now

(even with a known bug of this magnitude), we're going to work around

this entirely in the docs code. This code exposed the bug because it

uses the same request object for everything. In order to work around it,

we create new requests for each get_queryset() call as we iterate

through the resource tree.
While I was here I fixed up some problems I found in the fixtures with

the file attachment and screenshot counts, where the counts had somehow

ended up with the values typed twice (33 instead of 3, for example).

Built user manual.