Allow `@updateOrCreate` and `@upsert` to find models by columns other than `id`

I'm not super familiar with Lighthouse's internals, but I'm definitely willing to help if pointed in the right direction.

What problem does this feature proposal attempt to solve?

It looks like Lighthouse doesn't currently support the native Model::updateOrCreate() and Model::upsert() methods. See here for docs and here for the current @upsert implementation.

As such, there is currently no way to upserting a model by querying columns other than the model's primary key. So for example, you can't upsert a user by email unless email is the primary column. This also applies to nested mutations.

This feature would solve that use case.

Which possible solutions should be considered?

I think something like this could work:

extend type Mutation {
  updateOrCreateUser {
    id: ID
    email: String
    newEmail: String @rename("email")
    name: String
  } @updateOrCreate(find: ["id", "email"])

Or this?

extend type Mutation {
  updateOrCreateUser {
    id: ID @eq
    email: String @eq
    newEmail: String @rename("email")
    name: String
  } @updateOrCreate

Also, nested mutations could be considered:

input CreateUserBelongsTo {
  connect: ID
  create: CreateUserInput
  update: UpdateUserInput
  upsert: UpsertUserInput
  updateOrCreate: UpdateOrCreateUserInput
}

From there, using the feature would be rather straightforward:

mutation {
  updateOrCreateUser(
    email: "example@example.test"
    newEmail: "example-updated@example.test"
    name: "Updated Name"
  ) {
    email # "example-updated@example.test"
    name  # "Updated Name"
  }
}

To be honest, I'm not sure what an @upsert implementation would look like since 1) we probably don't want to write the "find" columns for every model we'd like to upsert and 2) Laravel's implementation looks a bit different from the current implementation, so backwards compatibility might be an issue.

I'm far from familiar with Lighthouse's internals and only somewhat familiar with Laravel's internals, so this proposed API might not work, but at least we have a starting point.

Start with src/Execution/Arguments/UpsertModel.php and compare its current behavior with Laravel's updateOrCreate() and upsert() documentation. Evaluate the proposed @updateOrCreate syntax, the alternative @eq approach, nested mutations, and backward compatibility. Done means the supported API and scope are clearly decided, including how models are found by non-primary-key columns.