There were three sources of N+1 queries here: the license check, the
path and namespace information, and the root namespace.

The license check was the worst. We were checking the license
information on each project individually. This meant we couldn't
paginate in SQL, but did so in Ruby, so it was not only an N+1, it was
loading too many records.

To fix this, we use the fact that this API endpoint can only return
projects in a particular namespace. License checks end up at one of two
places: for most instances, it's the instance's license itself. For
GitLab.com, where individual namespaces have their own plan, it's the
root namespace (subgroups can't have plans; they inherit their plan from
the root).

This means that we only ever need a single check. If it passes, every
project returned has the feature available. If it fails, we return a
404, like the other endpoints here. That way we can paginate in SQL, as
we should.

The path and namespace information N+1 was simple to fix: just preload
that information.

The final N+1 was on the root namespace, which we return as the `owner`
field for compatibility with GitHub. Again, this was always the same for
all items in the response, but we can't preload it easily because
different projects will be at different levels of the hierarchy.
Instead, we just calculate the root namespace once, and pass that as an
option to the entity. The entity uses that value if it's given, and
falls back to calculating it if it's not (in case this entity is used
elsewhere without that option).