Provide pre-filtered Project queryset to plugins in search()

[mikkonie]

Implementations for #1191 and #1898 would give a lot of project filtering responsibility to app plugins. Basically, all implementers of search() must do their own filtering for projects corresponding to the keyword parameters as well as user access. This increases the possibility of errors in implementation, as well as potential overhead for redundant Django database queries.

Apps do need to do some degree of project filtering anyway to e.g. filter for a specific permission (see filesfolders for an example). Nevertheless, requiring all apps to do their own filtering for the project keyword from ground up makes little sense, especially if we want to filter for partial title matches and such.

We should considering adding a projects argument to ProjectAppPlugin.search(). This argument would contain a QuerySet of Project objects already filtered down to the following:

• Projects for which the user has any role (local or inherited)
• Projects filtered down to a possible project UUID or (partial) project title via the project keyword.
• (+ possible future "global" project limiting we may come up with, without requiring changes in apps)

This would mean plugins implementing search would not have to worry about having to limit their queries to specific projects, instead simply passing the pre-filtered queryset to their own object filters. The plugin search implementations are, of course, still free to do further filtering down to specific projects when needed.

An alternative approach would be to filter results down in projectroles when we receive them from the plugins. Alas, this would potentially be very inefficient, as apps may need to return objects as lists instead of querysets, or query for something that's not even in the Django model (e.g. SODAR iRODS searches). This would mean the plugins querying and processing redundant data which then gets discarded by projectroles. Hence I don't believe this is the way to go.

Possible challenges and downsides:

• This will be a breaking change. No nice way to do it via depecation either, unless we want to create an alternative search() function and deprecate the old one.
• For efficiency, we need to provide the projects as QuerySet, not a list. We can't simply iterate through an array of already queries and call has_role() for each to catch all the inherited roles. That would perform badly anyway. However, there should be ways around this. Similar project filtering is already done for the project list, we could start looking there..

Comments are very much welcome. If we decide to go with this, we'd probably want to rework the pull request for #1191 right away..

[mikkonie]

We discussed this with @fmarotta and agreed to implement it in iterations:

1. Add this in the PR for project keyword feature (Add project limiting to search #1191), initially only supporting project UUID
2. Implement project partial title filtering in (Add title support for project keyword in search #1898), filter projects accordingly for the arg there
3. Possibly implement pre-filtering the project queryset by user roles in projectroles.

I'm not 100% sure if the last phase is necessary, as apps already do their own filtering by rules anyway. Might be a lot of work for questionable results. I'll think about this some more while we work on the first two phases.

[mikkonie]

Initial iteration done and merged as part of #1191. I'll leave this open until we have tackled the rest.