Bug 27034: Do not use path parameters on building the query

Bug 27034: Do not use path parameters on building the query

This patch simply removes the use of path parameters on building the
query in $c->objects->search.

The sample usage in the original tests considers a specific use case in
which the 'nested' resultset has the path param in its attributes:

GET /patrons/:patron_id/holds

In this case, $c->objects->search would be passed a Koha::Holds
resultset into which it would build a query. As the patron_id param can
be mapped into a Koha::Hold attribute, this works.

We don't actually use this approach in code. What we do is searching for
the patron, and properly return a 404 if the patron doesn't exist [1]. If it
exists, we actually call $patron->holds to get the related resultset, so
there's no gain in having the path param on the query afterwards.

That said, if we wanted to build:

GET /holds/:hold_id/pickup_locations

as the latter is a calculated value, from a resultset that doesn't
actually include a (mapped to some attribute) hold_id attribute, there's
no way to use it if it will automatically add the hold_id to the
pickup_locations resultset. It will give errors about hold_id not being
an attribute of Koha::Library (Branches.pm actually).

So this patch removes the automatic use of path parameters in
$c->objects->search. We can extract them in the controller and add them
to the passed resultset if required. But this patch removes a constraint
we have for building routes controllers right now.

[1] If we didn't return the 404, and we just passed a fresh Koha::Holds
resultset to be feeded with the patron_id, we would always return an
empty array in cases where the patron doesn't exist. This would be
misleading, but I'm open to discuss it. Design-wise.

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>