perf(storage): expose ability to peek on stream readers

[GeorgeMac]

Expose ability to Peek on reads.ResultSetStreamReader and reads.GroupResultSetStreamReader. The purpose being to allows creators of this type to pre-emptively peek at a frame before creating a cursor.

When creating multiple stream readers like these for multiple partitions and joining them into a single sequential or merged result set, a peek on each partition could be issued concurrently by the caller. This would allow us to quickly discard empty results, potentially reducing latency on reads.

• CHANGELOG.md updated with a link to the PR (not the Issue)
• Well-formatted commit messages
• Rebased/mergeable
• Tests pass
• http/swagger.yml updated (if modified Go structs or API)
• Documentation updated or issue created (provide link to issue/pr)
• Signed CLA (if not already signed)

[stuartcarnie]

Looks good!

My understanding is the effects of latency will be reduced as we are priming the upstream requests concurrently. This can be summarized as follows:

1. Client makes 1:N upstream requests and creates 1:N ResultSetStreamReader instances
2. Client maintains a pool of M goroutines to concurrently prime each ResultSetStreamReader, which occurs by calling Peek.
3. Client waits until all readers have been primed and then creates a merged ResultSet or GroupResultSet

---

The existing behavior of the merged ResultSet and GroupResultSet types will take care of any streams that are empty. Specifically, when Next is called and returns a null, EOF is assumed and the stream is discarded. These Next calls should return immediately, given they were primed in the earlier process.

[stuartcarnie]

The next step would be to merge this and update the IDPE Store type to parallelize the calls to Peek. Store is used by queryd to make the requests to the storage nodes.

[GeorgeMac]

@stuartcarnie my thoughts exactly 💯