add import bulk tuples

[akoserwal]

PR Template:

Describe your changes

• Add Bulk Import tuples

grpcurl -plaintext -d @ localhost:9000 kessel.relations.v1beta1.KesselTupleService.ImportBulkTuples <<EOM
  {
  "tuples": [
     {
    "resource": {
      "type": {
        "namespace": "rbac",
        "name": "group"
      },
      "id": "bobclub"
    },
    "relation": "member",
    "subject": {
      "subject": {
        "type": {
          "namespace": "rbac",
          "name": "user"
        },
        "id": "bob"
      }
    }
  }
  ]
}
EOM

response

{
  "numImported": "1"
}

• ...

Ticket reference (if applicable)

Fixes #

Checklist

• Are the agreed upon acceptance criteria fulfilled?

• Was the 4-eye-principle applied? (async PR review, pairing, ensembling)

• Do your changes have passing automated tests and sufficient observability?

• Are the work steps you introduced repeatable by others, either through automation or documentation?

  • If automation is possible but not done due to other constraints, a ticket to the tech debt sprint is added
  • An SOP (Standard Operating Procedure) was created

• The Changes were automatically built, tested, and - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)

• Are the agreed upon coding/architectural practices applied?

• Are security needs fullfilled? (e.g. no internal URL)

• Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)

• For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?

[lennysgarage]

Small change regarding prefixing relations before creating them

[merlante]

LGTM

[Rajagopalan-Ranganathan]

/lgtm - @akoserwal dont mind the failing github action of IQE - feel free to merge it

[lennysgarage]

LGTM

[alechenninger]

If I am reading this right, it looks like this method...

1. Gets a batch from the input stream
2. Starts a streaming RPC with SpiceDB
3. Sends one batch on that stream
4. Closes that stream

And then repeats for each batch.

However what we want is:

1. Start the spicedb stream
2. For each batch, send that batch to SpiceDB
3. Then close the stream after there are no more input batches (the client closes the stream on Relations end)

In other words, if a client has one streaming RPC with Relations, there should only be one equivalent streaming RPC with SpiceDB.

[akoserwal]

Good catch, thank you for the suggest. I update the code.

[alechenninger]

Not sure about this one. It's setting streamErr but checking err? And looking at example gRPC client streaming server docs, it looks like they show if the error from the client Recv() is not EOF, they return that rather than SendAndClose. What do you think?

[akoserwal]

yes, I agree.

[alechenninger]

LGTM! Thanks for iterating on it.