SearchBox should not search in all drives on the server

[Polleps]

The new SearchBox component introduced in #648 replaces the old Resource Selector component. This new component uses the search endpoint instead of the collections endpoint to generate a list of results. Currently we do not scope the search to the current drive because that would exclude results we might commonly want (e.g. some properties and most of the classes hosted on atomicdata.dev). Because of this the results shown can be any data that is public and on the same server as the users drive. This is not ideal because this data is most likely not relevant.

Some possible solutions:
1. Scope search to current drive: This would solve the problem but it would also exclude commonly used shared data like atomicdata.dev classes/properties.

2. Hardcode commonly shared data: We could hardcode the SearchBox component to also include some common data in the search, We would then need to define what this common data is and find a way to incorporate it in the results while still keeping the search query and relevance scoring of the search in account.

3. Have something similar to include_external in the search endpoint: Collections have an option to include external data that is cached in the server. We could add this to the search endpoint too. Pros: Probably easy to implement as this already sort of happens when you don't set a scope. Cons: not very flexible and might still include irrelevant data.

4. Allow for multiple scopes to be set in a search query: If we allow multiple scopes to be set in a search query we could scope the SearchBox to the atomicdata.dev drive in addition to the current drive. Implementing this would mean the search endpoint has to send a search request to the other scopes that are not hosted on the same server and then merge the results Pros: Most flexible solution, could be useful if we ever want to support multi node setups/search. Cons: Might add additional latency to search requests (Especially if we use blocking requests in the server).

5. Support multiple scopes on the client but not the server: The client supports multiple scopes and does a search request on each scope. This makes the search only as slow as the slowest server but we would have to send relevance scores to the client so it can properly merge the results.

If we go for option 4 or 5 we could also allow the user to add additional scopes to SearchBox searches. This would make it more easy to create classes/ontologies that integrate with existing data or apps which is one of the core philosophies of atomic data.

[joepio]

4 Seems to make a lot of sense. Instead of passing a single value, we accept an array of subjects as potential parents.

In tantivy, we build a big BooleanQuery from a bunch of others. One of them is a TermQuery for filtering by Parent.

We might use a BooleanQuery and iterate over the parent subjects, and add that resultin BooleanQuery to the query_list:

    if let Some(parent) = &params.parent {
        // Perhaps here we should create a new BooleanQuery::union?
        let query = build_parent_query(parent, fields, &appstate.store)?;

        query_list.push((Occur::Must, Box::new(query)));
    }

#[tracing::instrument(skip(store))]
fn build_parent_query(subject: &str, fields: &Fields, store: &Db) -> AtomicServerResult<TermQuery> {
    let resource = store.get_resource(subject)?;
    let facet = resource_to_facet(&resource, store)?;
    let term = Term::from_facet(fields.hierarchy, &facet);

    Ok(TermQuery::new(
        term,
        tantivy::schema::IndexRecordOption::Basic,
    ))
}