IPv6 bugs

[mantis-toboggan-md]

Summary

Fixes #15789
Fixes #15798
Fixes #15793

Occurred changes and/or fixed issues

• the UI will no longer modify stack preference when editing a cluster*
• the UI will no longer validate the stack preference input when editing a cluster*
• when adding a new machine pool to new or existing cluster, the UI will automatically check the 'enable IPv6' checkbox if at least one other pool has it checked
• when adding a new machine pool to an existing cluster, the UI will show the ipv6-related inputs if at least one of the existing pools is using an ipv6 or dual stack vpc/subnet

* I've made the UI more permissive during edits to accommodate clusters provisioned before the ipv6 feature was introduced. If a user previously provisioned a cluster with a dual-stack vpc or subnet and stack preference of ipv4, I don't think the UI should block them from clicking save and force them to change their stack preference.

Areas or cases that should be tested

The scenarios described in the linked issues above should be tested, as well as the following:

editing ipv6 clusters

1. Create an ec2 node driver cluster with a dual stack or ipv6 vpc/subnet selected in each pool (it can be only 1 pool)
2. Edit the cluster and verify that the ipv6 inputs are displayed but uneditable
3. Add a new pool to the cluster and verify that the ipv6 inputs are visible, and Enable Ipv6 is checked
4. Check the networking tab in the cluster configuration section and verify that the stack preference is still dual

editing ipv4 clusters

1. Create an ec2 node driver cluster with ipv4 vpc/subnet selected in each pool
2. Edit the cluster and verify that the ipv6 inputs aren't shown
3. Add a new pool and verify that the ipv6 inputs aren't shown
4. Check the networking tab in the cluster configuration section and verify that stack pref is ipv4

editing clusters with a networking/stack preference configuration the UI used to allow

1. Begin creating a new ec2 cluster, and configure the machine pool to use a dual stack vpc/subnet
2. Click 'edit as yaml' and change the stack preference to 'ipv4'
3. Click create
4. Edit the cluster again and verify that the stack preference hasn't been automatically changed to dual, and the save button is not disabled.

Areas which could experience regressions

Screenshot/Video

Checklist

• The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
• The PR has a Milestone
• The PR template has been filled out
• The PR has been self reviewed
• The PR has a reviewer assigned
• The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
• The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes
• The PR has been reviewed in terms of Accessibility
• The PR has considered, and if applicable tested with, the three Global Roles Admin, Standard User and User Base

[codyrancher]

Just for my own understanding, does it ever make sense for the stack preference to be ipv4 if all the machine pools are ipv6 enabled?

[mantis-toboggan-md]

Just for my own understanding, does it ever make sense for the stack preference to be ipv4 if all the machine pools are ipv6 enabled?

Not that I'm aware of but it can work. I really just think it would be confusing and look like a bug if a user had a cluster with such a configuration, upgraded Rancher to 2.13, tried to edit their cluster to change something completely unrelated, and couldn't click 'save' because some field the UI didn't show them before is throwing errors, despite the cluster configuration demonstrably working.