Consider refactoring registration authorization as a middleware

[dlongley]

          Moving this out for later refactoring and providing some context around what the "token" is and what it's for:

      if(cfg.registration.authorizationRequired.length > 0) {
        await _authorizeRegistration({req});
      }

Down below where helpers are defined:

async function _authorizeRegistration({req}) {
  const cfg = config['account-http'];
  const {authorizationRequired} = cfg.registration;
  const {authorization} = req.body;
  if(!(authorization?.type === authorizationRequired &&
    authorization.token)) {
    throw new BedrockError(
      `Authorization using "${authorizationRequired}" is required.`, {
        name: 'NotAllowedError',
        details: {
          httpStatusCode: 403,
          public: true
        }
    });
  }
  
  const remoteIp = req.socket.remoteAddress;
  await _verifyTurnstileToken({token: authorization.token, remoteIp});
}

Since the above fits the middleware pattern, I'll file an issue about potentially making this a middleware in the future.

I'm also not sure if using req.socket.remoteAddress is will work in deployment scenarios -- we'll need to figure that out before merging the PR to make sure we're pulling the IP from the right place.

Originally posted by @dlongley in #42 (comment)

[mattcollier]

@dlongley wrt to IP, would we use the same pattern we use here?

https://github.com/digitalbazaar/bedrock-kms-http/blob/f4fdfe48c55307b04290c607e42484a9a03f7ee6/lib/helpers.js#L24

[dlongley]

@mattcollier, yeah, sounds good -- definitely want to reuse that same pattern if it's working for us.