Subnet allocation errors should distinguish between IPv4 and IPv6 overlap

[bnaecker]

As part of #677, we added a query to verify that IPv4 and IPv6 subnets provided at the creation of a VPC Subnet don't overlap with any existing, non-deleted subnets. That query is implemented here.

This doesn't allow us to tell which type of subnet (v4 or v6, or both) was at fault. That's a problem specifically when a user creates a new subnet, specifying an IPv4 range that overlaps with an existing one, but allowing the system to auto-generate an IPv6 error.

As an example, suppose we have an existing organization, project, and default VPC. We can create a subnet like this:

$ curl -sSq http://127.0.0.1:12220/organizations/my-org/projects/my-proj/vpcs/other-vpc/subnets -X POST -d '{"name": "new-subnet", "description": "a new subnet", "ipv4_block": "192.168.1.0/24"}'

Running that exact command a second time yields:

bnaecker@shale : ~/omicron $ curl -sSq http://127.0.0.1:12220/organizations/my-org/projects/my-proj/vpcs/other-vpc/subnets -X POST -d '{"name": "new-subnet", "description": "a new subnet", "ipv4_block": "192.168.1.0/24"}'
{
  "request_id": "fb8d38e1-8079-4481-a3a7-c839b0ec4f7b",
  "error_code": "Internal",
  "message": "Internal Server Error"

Looking at the Nexus logs, we can see this error message:

Mar 07 17:51:57.467 INFO request completed, error_message_external: Internal Server Error, error_message_internal: Unable to allocate unique IPv6 address range for VPC Subnet, response_code: 500, uri: /organizations/my-org/projects/my-proj/vpcs/other-vpc/subnets, method: POST, req_id: fb8d38e1-8079-4481-a3a7-c839b0ec4f7b, remote_addr: 127.0.0.1:48325, local_addr: 127.0.0.1:12220, component: dropshot_external, name: e6bff1ff-24fb-49dc-a54e-c6a350cd4d6c

That comes from this line, which is part of a retry loop for generating a random IPv6 subnet. Really, the IPv6 subnet part is a red herring -- the issue is that the IPv4 subnet is exactly the same as the existing one, but we have no way to know by inspecting the error messages in the existing query.

What we want here is to generate an invalid request error, being clear that the issue is the overlapping IPv4 subnet that the user provided. That query needs to be adjusted to provide different error messages in these two cases.

[bnaecker]

Closed by #760