Secure nextUri with a slug

[rschlussel]

Backport trinodb/trino#561

[mayankgarg1990]

Me and @wenleix were actually talking about something similar for worker communication to avoid people from guessing the worker URL to fetch intermediate data.

[arhimondr]

LGTM % please wait for the build to pass

[rschlussel]

1. not sure what's going on with that test, doesn't seem like a related failure, but I've restarted it 3 or 4 times at this point
2. @rongrong raised the point that it would be more secure to generate a new slug for each request. That way if the client leaks the request uri (e.g. logs it), you still won't be able to access the rest of the results. Implemenation-wise i think that means updating the slug in createNextResultsUri (and synchronizing it to keep it threadsafe). Does anybody have concerns with this approach?

[mayankgarg1990]

Re: new slug every time - as of now - if somehow there is an out of order request we would end up getting "query not found" as getQuery() would return a null. As per my look at the code - if you issued the same request again (maybe client side retry) - we would just return the same result set:

        // is the a repeated request for the last results?
        String requestedPath = uriInfo.getAbsolutePath().getPath();
        if (requestedPath.equals(lastResultPath)) {
            if (submissionFuture.isDone()) {
                // tell query manager we are still interested in the query
                queryManager.recordHeartbeat(queryId);
            }
            return Optional.of(lastResult);
        }

In my opinion we should maintain this behavior with the new implementation as well

[rschlussel]

You already can't get results out of order, but I didn't think about getting the same result twice. Seems reasonable to leave as is for now. We can do more investigation about whether it's worth breaking this feature.

[rschlussel]

We could also cache the previous slug, though for that case.

[rongrong]

This PR is strictly better than before so I don't see reasons to block it. But if the client logs the url then a unique slug per query is not very helpful. We can improve that in a separate PR though if people feel more discussions are needed.