feat: add validator response fields for ipv6, ipv4 and http status code

[s3lph]

We sometimes have cases where the validator yields seemingly unexpected results due to some edge case configuration.

A recent example for such a case is SpaceApi/directory#288, where the validator receives a 403 with its default user agent, however most other user agent strings work without any issue, which made this rather cumbersome to troubleshoot.

This PR adds the following features to the /v2/validateURL API endpoint:

• Establish connections using both IPv6 and IPv4, and record the result in the response fields reachableIPv6 and reachableIPv4.
• Record the actual HTTP status code that the validator received in the response field httpStatus.

[dbrgn]

Thanks, nice! Left some comments (but keep in mind that my Go knowledge is very superficial).

[dbrgn]

Is it intentional that the checks below happen after setting the Origin header, but ther egular Reachable-Check above happens before?

Also, couldn't the validationResponse.Reachable value just be validationResponse.ReachableIPv6 || validationResponse.ReachableIPv4?

[s3lph]

Is it intentional that the checks below happen after setting the Origin header, but ther egular Reachable-Check above happens before?

The thing that happens in L230-234 is the preparation of the request, not the actual sending. The single request will then be used 3 times below. As far as I understand it, setting .Reachable = false in L232 is actually a no-op, as the variable is initialized as false anyway. The actual "regular" check happens in L256 and onward.

Also, couldn't the validationResponse.Reachable value just be validationResponse.ReachableIPv6 || validationResponse.ReachableIPv4?

Unfortunately not. validationResponse.Reachable is actually a bit of a misnomer, as it also checks for e.g. the HTTP status code (L274). With the IPv6 and IPv4 request, reachable just means "we got a HTTP response". I'm unsure whether this is the best approach, but it's one that doesn't break the semantics of existing API fields. You can look into SpaceApi/validator-web#14 to see how I'm using the new API fields in combination with existing ones without breaking the existing ones.

If we decided to change the semantics of validationResponse.Reachable instead, I see it as a breaking change warranting a new major API version.