Description

Right now when looking up resources via gRPC calls, every streamed resource includes a continuation token, including the last resource that gets streamed. This confuses the callers of the service because they assume there are more elements to fetch, and therefore they have to make one last call to ensure that no more elements are available in Kessel. Summarizing:

• Assuming there are 1,500 resources in Kessel that want to be fetched.
• * One request is made which makes the Relations API stream 1,000 resources, with the last one having the continuation token "A".
• * Another request is made with continuation token "A", and another 500 resources are streamed. The last resource, in this case, has the continuation token "B".
• * The caller sees that the last element has another continuation token, and since its different to the first one "A", it assumes that there's more to fetch and makes another request with the continuation token "B".
• * Kessel doesn't send any more resources, and the caller now knows that they can stop asking for resources.

This is true for any caller that integrates with the lookup resources' endpoint.

Notes:
https://discord.com/channels/844600078504951838/844600078948630559/1333841251677634631 - spiceDB response in discord

Acceptance criteria

• The last streamed element returns an empty continuation token in the last element when there are no more elements left to stream back to the caller.

Please note that having reached the maximum streamable elements per response —currently capped at 1,000 resources— should not make the last element return an empty continuation token if there are more resources that could be streamed in a follow-up call.