Add `insecure_allow_http_bind_ips` to client redirect settings

[r0mant]

Teleport SSO connectors currently support specifying allowed https redirect domains that are used in conjunction with tsh --callback flag to allow redirecting SSO callback to an address other than localhost:

https://github.com/gravitational/teleport/blob/fa64296694a824e58bdea9d999ec8edc9b9ce0e3/api/proto/teleport/legacy/types/types.proto#L4436-L4439

Currently only redirects to https addresses on port 443 are supported, however some customers that use tsh login callback functionality to implement headless login pattern on their engineers' dev instances require support for plain http redirect to a set of arbitrary IPs. To solve this, add a new insecure_allowed_cidr_ranges field to client redirect settings that accepts a list of CIDR ranges that are valid for the redirect.

spec:
  client_redirect_settings:
    allowed_https_hostnames:
    - *.example.com
    insecure_allowed_cidr_ranges:
    - 192.168.1.0/24

To do that we need to:

• Add the field to the resource spec.
• Update client redirect validation appropriately.
• Make sure client redirect via http to an IP from the range works fine.

[espadolini]

Should we pick a name that clarifies that all ports will be allowed for those addresses? Do we care about restricting ports in some way?

Is https allowed for these CIDR ranges?

Are we ok with only CIDRs or should we allow for more flexibility with a regexp on hostnames instead? (which would make it possible but quite a bit more annoying to configure a specific local range, admittedly: ^192\.168\.3\.([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])$)

We should ensure that the CIDR parsing works with ipv6 addresses as hostnames, too.

[r0mant]

• Let's allow any port, I don't think it should be reflected in the name.
• Yep, I don't see an issue with allowing both HTTP and HTTPS.
• I think having a separate flag for specifically CIDRs is more straightforward from UX standpoint.
• Yep, good call about IPv6.

@capnspacehook FYI^