Support for specifying which generated route table to assign to subnets

### Is there an existing issue for this? - [x] I have searched the existing issues ### Description **The Problem:** Currently, when defining subnets within `hub_virtual_networks`, the `route_table.assign_generated_route_table` attribute is a boolean. If `true` (the default), it assigns a generated route table. However, the module creates two distinct route tables: one for firewall-related routing (e.g., associated with `AzureFirewallSubnet` or for traffic via the firewall/NVA) and another for general user subnets. There isn't a direct way to specify *which* of these generated route tables a particular custom subnet (like "untrust" or "trust" zones for a custom NVA) should use. To assign the module's generated "firewall" route table to such a subnet, one must: 1. Set `assign_generated_route_table = false`. 2. Provide `route_table.id` by looking up the generated firewall route table's ID using a `data "azurerm_route_table"` block. This creates a dependency that can lead to needing a two-pass apply (`terraform apply` once to create the RT, then again for the data source to find it and associate it), or can complicate dependency chains, especially when provisioning NVA infrastructure that relies on these specific route tables. --- **Proposed Solution:** Enhance the `subnets.*.route_table` object to allow more granular selection of the generated route tables. Instead of just a boolean `assign_generated_route_table`, consider one of the following approaches: 1. **Change `assign_generated_route_table` to a string/enum:** This attribute could accept values like: * `"user_subnets"` (or a similar key, to assign the standard user subnets route table, keep this as default). * `"firewall"` (or a similar key, to assign the firewall-associated route table, ideal for custom NVA trust/untrust subnets). * `"none"` or `null` (if an explicit external `id` is provided, or no route table is desired). Example: ```terraform subnets = { untrust_nva_subnet = { name = "sn-nva-untrust" address_prefixes = ["10.0.0.0/28"] route_table = { assign_generated_route_table = "firewall" // Assigns the module's generated 'firewall' RT } }, trust_nva_subnet = { name = "sn-nva-trust" address_prefixes = ["10.0.0.16/28"] route_table = { assign_generated_route_table = "firewall" // Assigns the module's generated 'firewall' RT } }, workload_subnet_a = { name = "sn-workload-a" address_prefixes = ["10.0.0.32/28"] route_table = { assign_generated_route_table = "user_subnets" // Explicitly assigns the 'user_subnets' RT // Or this could be the default if not specified. } } } ``` 2. **Introduce a new attribute:** Alternatively, keep `assign_generated_route_table` as a boolean for backward compatibility (defaulting to `user_subnets` RT if `true` and no other specifier) and add a new optional attribute like `generated_route_table_type: "firewall" | "user_subnets"`. --- **Why this would be helpful:** * **Simplifies Configuration:** Allows direct declarative association of subnets to the appropriate type of module-generated route table, which is crucial for NVA deployments and DMZ setups. * **Avoids Cyclical Dependencies/Two-Pass Applies:** Eliminates the need for `data` blocks to look up IDs of route tables created within the same module execution, leading to a cleaner `terraform plan` and `apply` process. * **Improved Usability:** Makes the module more intuitive for common hub patterns where specific subnets (e.g., for NVAs, DMZs, or other specialized workloads) need to be associated with the firewall's route table or a standard user route table. ---