Directly use Zed lake query endpoint

[philrz]

As described in brimdata/super#2680, the current API is allowing Brim to access data in pools via the legacy "search" endpoint, but there's functionality such as join from multiple pools that will only be possible when the app starts directly using the new Zed lake "query" endpoint.

[philrz]

I took a shot at verifying the work thus far with Brim 0dcf10c by attempting this multi-pool join derived from the Zed docs:

from (
  fruit.ndjson => sort flavor;
  people.ndjson => sort likes;
) | inner join on flavor=likes eater:=name

This produced a backend error Upstream data source blocked by 'from operator'. I could see in Wireshark that the query being sent to the backend was:

{"query":"from '0x0dcfc31bd80817b052e0c8eb90a8297af928a8ea' | from (   fruit.ndjson => sort flavor;   people.ndjson => sort likes; ) | inner join on flavor=likes eater:=name | head 10000"}

@nwt proposed a fix for this:

Rather than prepend a from to the query, the app should set the head field in the request, like this.

{
 "query": "from (   fruit.ndjson => sort flavor;   people.ndjson => sort likes; ) | inner join on flavor=likes eater:=name | head 10000",
 "head": "0x0dcfc31bd80817b052e0c8eb90a8297af928a8ea"
}

[philrz]

Verified in Brim commit de44850.

Now with the benefit of the additional fix from #1836, we can execute the multi-pool join shown in the Zed docs from within the Brim app, as shown in the attached video:

Verify.mp4

In a discussion with the Dev team, it was confirmed that the current fix added in #1836 is only limited to queries where the from leads off the query entered by the user in the search box. That is, queries with from nested somewhere deeper inside the Zed are not expected to work yet.

Thanks @mason-fish!