feat: [M3-6752] - Assign Linodes to Subnet drawer

[coliu-akamai]

Description 📝

Add new drawer for assigning linodes

TODOS

• fix error handling
• unit tests
• write up findings on how to show that linodes need rebooting issue (ty Alban!!)
• general cleanup (+ looking into further cleanup...)
• unassign linodes that were already assigned
• downloading assigned linodes

Major Changes 🔄

• added Subnet Assign Linodes Drawer + relevant tests
• Had to update validation for the linodeInterfaceSchema (this expected an array of interface objects, but the endpoint that used this as validation only wanted a single interface)
• Add new component, RemovableSelectionsList, since this is used in both Un/assign linode flows

Preview 📷

selecting linode	after selecting linode

How to test 🧪

yarn test SubnetAssignLinodesDrawer
yarn test SubnetActionMenu
yarn test RemovableSelectionsList

Test the following flows: (****integration tests for these flows will be handled in a separate ticket/pr!)

• assign a linode with only one configuration (default) (confirm that linode is removed from the list of linodes you can assign)
  • test auto-assigning a VPC ipv4 vs not auto-assigning
• assign a linode with multiple configurations (confirm that linode is removed from the list of linodes you can assign)
  • test auto-assigning a VPC ipv4 vs not auto-assigning
• test that after assigning a linode, you can unassign it in the same drawer and that it appears back in the list of linodes that you can assign
• test assigning a bad ipv4 - both nonsense one and a valid ip that is not in subnet range (should error)
• test: the button to assign a linode should be disabled if a linode is not selected
• test: if a linode has multiple configs but we have not selected one of these configs, the button to assign should be disabled
• test: assigning a linode with no configs (should error)
• double check to make sure that linodes now appear in the subnet you assigned them to in the subnet table
• assigning the same linode to multiple subnets (both within the same vpc and not)
  • note: there's a followup ticket (m3-7157) to make sure only the ips specific to the linode and subnet are shown, not all ips
• any flows that use the linodeInterfaceSchema still have the same functionality (creating a Linode, creating a Linode config, updating a linode config)
• downloading the CSV (no linodes assigned, 1+ linodes assigned, determine that CSV accurately reflects the linodes in the 'Linodes assigned to Subnet (x) list) (should have linode's ID, label, public ipv4 at minimum, may include more fields)
• dismissible banner warning for rebooting linodes appears if there's 1+ linode assigned to a VPC
• double check that you can't assign linodes to a subnet if you don't have the permissions for that specific vpc

++anything else you can think of that I haven't mentioned here

Honestly, wouldn't recommend using the MSW and instead using just your dev account as it's hard to see changes/confirm all the error handling on it

[coliu-akamai]

• The file for the SubnetAssignDrawer itself... is pretty big 😅 -- I'll be looking into potentially breaking it down (maybe moving the form portion into a different file? idk for sure yet).
• There are quite a few similarities between this drawer and the Unassign Linodes one -- probably worth trying to cleanup/abstract more after both get merged in!
• After assigning a Linode to a subnet, if we go back to the Linode's page and delete it, the Linode will still appear to be assigned to the subnet (even though the Linode no longer exists) unless we refresh the page, because we don't invalidate any subnet/vpc related queries when deleting Linodes. We could potentially look into this link (ty Dajahi!) -- could be worth following up on this in a separate ticket?

[coliu-akamai]

The changes in this file match @jaalah-akamai 's ticket for the Unassign Linode subnet drawer (copy-paste tbh), since they're super similar -- may have merge conflicts later

[coliu-akamai]

Similarly, a lot of the styling in this file matches/copies @jaalah-akamai 's ticket as the lists in the UX mockup are the same -- we could move this styling to a common styling file or have both drawers import their styling from here later!

[coliu-akamai]

Unit tests here are pretty basic tbh, will need to be a lot more thorough in the integration tests (see all the cases to test for 😭)

[coliu-akamai]

Adding vpc.region as a prop to the SubnetsTable because when determining which linodes we can assign to a subnet, we want them to be in the same region as the VPC

[dwiley-akamai]

Went down the functionality checklist and everything LGTM ✅ 🚀

Going ahead and approving but I did leave a few small comments

[abailly-akamai]

Looks great! very nice feature and coverage.

See my comments, also adding a few things here:

1. not sure if related to your PR but autocomplete seems to be complaining about the values passed to it
   

2. Available IP address 124? is that accurate, mocked?
   

[coliu-akamai]

@abailly-akamai

• hm.. I'm getting the Autocomplete warnings as well, and I'm wondering if that has to do with the fact that after selecting and assigning a linode (this triggers a rerender), we remove the assigned linode from the autocomplete's options, and the autocomplete triggers that warning before we rerender. If so, getting rid of the warning may be pretty complicated, will look more into it. Also interesting to note - I don't see this warning pop up at commit a328b4c8d703237e3cd3d72c67f5271adc18e795, but this version has its own issue (depends on the API erroring for determining what linodes to keep track of) >> resolved!
• for VPCs, available IP addresses = # of total IP addresses (128 in this case) - 4 (the reserved IPs for VPC stuff). 124 seems correct based on that
• Looking into the table accessibility issues as well -- may move that to another ticket, since it seems more related to the CollapsibleTable component [m3-7181]

[abailly-akamai]

@coliu-akamai thx for confirming!

Available IP address 124? is that accurate, mocked?

Let's change to "Number of available IP Address: {x}" to make it clearer cause it could look like a part of an ip address for instance

[abailly-akamai]

Looks great thanks for the changes and the follow up tasks - nice job! not an easy one 🚢