Remove state ID / transaction ID

[bifurcation]

As @kkohbrok points out in a comment on #41, it should be possible to remove the state_id and transaction_id fields from the gRPC API. Instead, the clients could rely on MLSPlaintext.group_id and Welcome.secrets.key_package_hash.

The trade-off would be that:

• The gRPC wrapper code would have to inspect the contents of the messages instead of just passing them through.
• In particular, for the Welcome case, it would have to search through Welcome.secrets looking for a known hash.
• In order to allow multiple tests to be in flight at once, group_id values would have to be chosen so that they did not collide.
• The test runner would only be able to reference the latest state of the group at a given client, which might make it impossible to test some error cases.

[bifurcation]

I have a weak preference for keeping the transaction_id, and a stronger preference for keeping state_id. In the former case, mainly seems like more work for the wrapping code to look up the right KP, if this isn't something that's native in the stack. In the latter case, the collision concerns seem hard to manage unless we make a pretty hard presumption that the test runner here will be the only gRPC client; and the flexibility seems valuable.

That said, it seems like it could be fair game for an MLS client implementation (gRPC server) to ignore these fields if they don't need them. For example, the client could just fill in a constant value. The only catch there is that such clients wouldn't be able to do tests that need to reference old epochs.

[kkohbrok]

Thanks for summarizing the trade-offs.

The test runner would only be able to reference the latest state of the group at a given client, which might make it impossible to test some error cases.

Can you elaborate on what you mean by that point? Is that assuming that state_id changes with each epoch, allowing you address old epoch states? (Assuming clients keep that state around, that is.)

Also what concerns do you have regarding collisions? I would assume that group_id is just a random string of sufficient length to avoid collisions.