Updates to IP Pools

[smklein]

We had a sync on 12/14/22 on this: https://drive.google.com/file/d/1ffOrgbYsoomSaNeo284FX1EmUpWMJqFR/view?usp=share_link

• Remove "project ID" field: [nexus] Remove project_id, rack_id from IP pools #2056
• Remove "rack ID" field: [nexus] Remove project_id, rack_id from IP pools #2056
• (Later) add bit to distinguish between internal / external visibility?: [nexus] Remove project_id, rack_id from IP pools #2056
• Ensure Nexus can point to the one with "internal visibility" only: [nexus] Remove project_id, rack_id from IP pools #2056
• (Later) add field for AZ?

[smklein]

Summary from @rmustacc :

• External IPs are best thought of like a hardware resource due to their finite nature and is much more like DRAM than say VMs or volumes in nature.
• Fundamentally an IP pool represents a disjoint group of IPs with the same connectivity properties. For example, all just Internet facing public IPs or say a private VLAN.
• Customers eventually want to be able to constrain groups of projects to specific IP pools. While this isn't part of the MVP, the reality is that it's more than one.
• Internal services want to get their configuration for how to find addresses initially via IP Pools (e.g. nexus, external DNS, NTP, routing though that's a bit more nuanced).
• The system level IP Pools API is going to be simplified right now to mostly represent a fleet (though kind of AZ) resource and the only real acl style bit is whether it's internal or external.
• Eventually we'd like a project-specific API to list the IP pools that are accessible in that context separate from the the system level API to make it obvious what is and isn't usable. This may be worth it for MVP.
• Longer term (e.g. not for the MVP) we want to do better with defaults at a project level or similar and figure out what more fine-grained ACLs might look like on IP Pools, but that's not today.

[david-crespo]

Closing in favor of issues I'm creating for the followup work to #3985