Deny email registration for Matrix

[bheesham]

We already allowed email registrations to Matrix, so we can't disable this
connection, since that would break logging in for existing users.

That leaves us with only one option: deny at pre-user-registration.

Jira: IAM-1617

---

Plan for prod

  # auth0_action.deny_registration will be created
  + resource "auth0_action" "deny_registration" {
      + code       = <<-EOT
            // Reject users from registering for an application (by client id) using a
            // specific connection.
            //
            // This is a workaround for disabling a connection entirely for an application,
            // since we may have allowed registrations already.
            //
            // If we instead disabled the connection then we'd break logins for users who
            // only have that connection available.
            //
            // DEBT(bhee): LDAP's connection name is
            // * `Mozilla-LDAP` on prod;
            // * `Mozilla-LDAP-Dev` on dev.
            //
            // If we need to deny registrations on those, for some reason, we'll need to
            // think of a better way. Connection Ids are not stable across tenants either.
            
            exports.onExecutePreUserRegistration = async (event, api) => {
              const CLIENT_CONNECTIONS_DENYLIST = {
                // Matrix, IAM-1617
                pFf6sBIfp4n3Wcs3F9Q7a9ry8MTrbi2F: ["email"],
              };
            
              const denylist = CLIENT_CONNECTIONS_DENYLIST[event.client.client_id] ?? [];
            
              if (denylist.includes(event.connection.name)) {
                return api.access.deny(
                  `Not allowed to register for ${event.client.name} using ${event.connection.name}.`
                );
              }
            
              return;
            };
        EOT
      + deploy     = true
      + id         = (known after apply)
      + name       = "denyRegistration"
      + runtime    = "node22"
      + version_id = (known after apply)

      + supported_triggers {
          + id      = "pre-user-registration"
          + version = "v2"
        }
    }

  # auth0_trigger_actions.pre_user_registration_flow will be created
  + resource "auth0_trigger_actions" "pre_user_registration_flow" {
      + id      = (known after apply)
      + trigger = "pre-user-registration"

      + actions {
          + display_name = "denyRegistration"
          + id           = (known after apply)
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

[bheesham]

Following-up via Slack with @denschub about if we need to notify anyone, since this would be a breaking change.

[gcoxmoz]

I'm not sure I trust my understanding of the explicit code, but I get where you're going enough to think you're on a good path and I don't see anything so scary it shouldn't proceed, so, cautious r+ from me as a reviewer-of-last-resort

[skyschub]

I don't think we need to do any proactive comms here. We aren't breaking existing users, only new registrations, so I don't think anyone cares. I'll edit the wiki page and keep an eye on our feedback channels, but besides that, I don't see a need to be vocal about this. If I see a lot of complaints, we can put something out.