Fix incorrect logic in resolve_networks function

[shurkys]

Description The resolve_networks function contains incorrect logic for replacing network variable placeholders with their corresponding network IDs. The current implementation uses the first key in the network hash, which can lead to incorrect substitutions if the key order does not match.

To Reproduce Steps to reproduce the behavior:

1. Create a template with vm_template_contents containing network variable placeholders (e.g., $CUSTOM1_VAR).
2. Define networks_values with multiple network entries.
3. Execute the resolve_networks function with the template.
4. Observe that the variable placeholders might be replaced with incorrect network IDs due to key order mismatch.

Example in https://github.com/OpenNebula/terraform-provider-opennebula/issues/527

Expected behavior The variable placeholders in vm_template_contents should be replaced with the correct network IDs based on the matching keys.

Details

• Affected Component: OneFlow
• Hypervisor: KVM
• Version: Current development version

Additional context In continuation of PR #6522 (Fix flow key order hardcode), there were changes made in commit 0d1ac37583a43bac6454c3e939fa014e7672c3d2, but the resolve_networks function was not updated. The current logic in the resolve_networks function is incorrect and should be updated for better accuracy.

Current Logic:

role['vm_template_contents'].gsub!(
    '$'+key[0],
    net[net.keys[0]]['id'].to_s
)

In the current implementation, net[net.keys[0]] is used to get the network value. This approach can lead to incorrect results if the order of keys in net does not match key[0].

Suggested Improvement:

role['vm_template_contents'].gsub!("$#{key[0]}", net[key[0]]['id'].to_s)

By using net[key[0]] directly, we ensure that the correct network value corresponding to key[0] is used, making the function more reliable.

Progress Status

• [x] Code committed
• [x] Testing - QA
• [x] Documentation (Release notes - resolved issues, compatibility, known issues)