Module net-vpc fix for reserved ranges

[jamesdalf]

With the recent changes regarding the prefix for the PSA ranges, it created an issue for allocating the correct reserved ranges for a service producer. In the current version, each service producer will be allocated all ranges in the reserved ranges. This appears to only happen when there are multiple service producers defined.

This fix in this PR ensures that, within the psa_configs object, only the ranges specified in the service producer are reserved not all.

Example
In the following psa_configs, we expect to see that servicenetworking.googleapis.com has reserved ranges for google-services-0 and psa. However, in the plan we see it also has netapp-services-0, example-producer, and example-producer2

The fix would avoid the three extra ranges

"psa_configs": [
    {
      "ranges": {
        "google-services-0": "...",
        "psa": "..."
      },
      "service_producer": "servicenetworking.googleapis.com",
      "range_prefix": "",
      "export_routes": true,
      "import_routes": true
    },
    {
      "ranges": {
        "netapp-services-0": "..."
      },
      "service_producer": "netapp.servicenetworking.goog",
      "range_prefix": "",
      "export_routes": true,
      "import_routes": true
    },
    {
      "ranges": {
        "example-producer": "...",
        "example-producer2": "..."
      },
      "service_producer": "example.servicenetworking.goog",
      "export_routes": true,
      "import_routes": true
    }
  ]

Here we can see that for the servicenetworking.googleapis.com service producer it adds all ranges to the reserved_peering_ranges

  # module.spoke-vpcs["dev"].google_service_networking_connection.psa_connection["servicenetworking.googleapis.com"] will be updated in-place
  # (moved from module.spoke-vpcs["dev"].google_service_networking_connection.psa_connection[0])
  ~ resource "google_service_networking_connection" "psa_connection" {
        id                      = "..."
      ~ reserved_peering_ranges = [
          + "example-servicenetworking-goog-example-producer",
          + "example-servicenetworking-goog-example-producer2",
            "google-services-0",
          + "netapp-services-0",
            "psa",
        ]
        # (3 unchanged attributes hidden)
    }

Plan from the fix for service producer example.servicenetworking.goog

  # module.spoke-vpcs["dev"].google_service_networking_connection.psa_connection["example.servicenetworking.goog"] will be created
  + resource "google_service_networking_connection" "psa_connection" {
      + id                      = (known after apply)
      + network                 = "projects/deaut-dev-net-spoke-0/global/networks/dev-spoke-0"
      + peering                 = (known after apply)
      + reserved_peering_ranges = [
          + "example-servicenetworking-goog-example-producer",
          + "example-servicenetworking-goog-example-producer2",
        ]
      + service                 = "example.servicenetworking.goog"
    }

---

Checklist

I applicable, I acknowledge that I have:

• Read the contributing guide
• Ran terraform fmt on all modified files
• Regenerated the relevant README.md files using tools/tfdoc.py
• Made sure all relevant tests pass

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[ludoo]

The changes assume you would use a different prefix for the ranges of each service. :) This should work, would you mind signing the CLA and adding an example to the README, so we have a test for this use case?

[jamesdalf]

I had the wrong email in my commit so it didn't show i had already signed the CLA.

I will update the readme. For our use case, we don't want to add the prefix as we have existing psa ranges configured without a prefix. We actually separated out the external service producers from our net-vpc module as it didn't support that use case at the time.

We want to be able to control what ranges are reserved for a service producer. I think this change will achieve that. However, if there is another way to achieve that, its also fine! This was just the solution I found when trying to fix it for our use case.
It seems to handle our existing psa ranges and if we add a new one in the "new" way that appends a prefix based on the service producer name

[jamesdalf]

I updated the readme with an example. I hope it is ok. The one thing I am not sure about is creating the testing for such an example.

[ludoo]

The contributing guide in the repo root explains how to handle tests. The simplest thing you can do is add a tftest comment line in the example, with the number of modules and resources in the plan.