Allow optional specification of IDs when creating entities

[mike-marcacci]

Currently, AuthX assigns IDs to newly-created entities. This means that you would have to make multiple requests to, say, add a user, and then assign the user to a role (since you need the user’s ID to assign to the role). Because we used UUIDs here, we can make it so that a GraphQL client can optionally specify an ID when creating a new entity. This will enable batching of mutations that include entity creation.

[mike-marcacci]

After thinking through the security implications of this, I've realized that this change is more involved than originally expected.

The real benefit of making IDs configurable is that a "create" request gains some degree idempotence. That is, if a request fails (perhaps due to a network issue) the sender can safely retry it without risking creating a final state where multiple copies were created.

My current plan is to update an entity on collision so that the specified fields match. There may be scenarios where this is not possible, though, so this is not a final decision.

Another strategy would be to ensure that the existing entity is identical to the one that would be created by the current request.

Either way requires additional checking of permissions, though, as we need to make sure we can either update or read the relevant fields on the existing entity (which may belong to a different user, etc).

[mike-marcacci]

I have several additional thoughts on this. I'm still debating between the "update on collision" and "error on incompatible collision" strategies, and the following is just a "brain dump":

• We will consider the existence of an entity identified by it's id a non-sensitive piece of information for the goals of this project. That is, if a party is aware of a particular UUID, we don't need to worry about whether or not we can confirm its existence. This does NOT apply to entities identified by some other mechanism, such as an email address.
• As I work my way through #38, I'm realizing that not all fields on "create" inputs lend themselves to updating. For example, an authorization is created with a userId and grantId, which must never be changed. This means that we will have to return a "collision error" in at least some cases, and the appropriate error handling must exist in any user interface.
• Both strategies expose a potential for escalation of privileges (albeit a very impractical one), in that a user with "create" access and no "read" access might send create requests with different values in a non-readable field, to essentially "poll" for the correct one. Again, this is quite impractical, but nonetheless possible.
• Perhaps the safest solution is to simply error on any collision, even where values are identical. This is by far the simplest solution, and could easily be extended with one of the strategies proposed earlier. Unless I am given (or discover) a reason that this is inadequate, this will probably be my initial implementation.