Verify the customer's Route 53 access role and write the connection's records with it

Route 53 access role, second step. Send the RoleArn output of the stack the customer created from the route53-role:start link. CustomDomain™ assumes the role with the connection's external ID and checks that AWS refuses the role both without an external ID and with a wrong one: a role that lets CustomDomain™ in without the right external ID is refused and never stored. It then finds the hosted zone and writes the connection's records through Route 53 with the role's temporary credentials, and the connection moves to propagating exactly as after an API key apply. The verified role is stored, so calling this again with an empty body re-applies the records with it. Branch on code: route53_role_not_started (409), route53_role_arn_invalid (400), route53_external_id_mismatch (the role was made from another link), route53_role_not_found (AWS refused the role), route53_external_id_not_required, route53_zone_not_found (no public hosted zone for the domain or a parent of it), route53_zone_ambiguous (two public hosted zones share the name and the role can read both), route53_access_denied (the role cannot read that zone, or cannot write a record the connection needs) and route53_record_conflict (another record holds the name with a type the needed record cannot share; delete or change it in the Route 53 console), all 422, and route53_unavailable (503, nothing was changed, try again).