Phasing out use of n1 machines in favor of n2 machines on GKE

[consideRatio]

I've researched to conclude that n2 machines seems like an almost pure win with:

• n2-highmem is more cost effective per RAM
• n2-highmem is more cost effective per CPU performance
• n2-highmem has 1:8 CPU:RAM ratio, while the n1 stands out with the unique ratio of 1:6.5

Proposal

• To change anything we touch anyhow to n2 from n1
  Exception: we need to retain n1 nodes for GPU machines as they may only come as n1 variants
• To update templates so new clusters are bootstrapped with n2 machines by default

Current use of n1 machines

• 2i2c-uk core nodes
• 2i2c-uk user nodes
• cloudbank core nodes
• cloudbank user nodes
• cloudbank dask nodes (*use only one node pool with n2-highmem-16)
• m2lines core nodes
• m2lines user nodes
• m2lines dask nodes (*use only one node pool with n2-highmem-16)
• meom-ige core nodes
• meom-ige user nodes
• meom-ige dask nodes (*use only one node pool with n2-highmem-16)
• pangeo-hubs core nodes
• pangeo-hubs user nodes
• pangeo-hubs dask nodes (*use only one node pool with n2-highmem-16)
• two-eye-two-see core nodes
• two-eye-two-see user nodes
• two-eye-two-see dask nodes (*use only one node pool with n2-highmem-16)
• two-eye-two-see neurohackademy nodes

*In #2687 I'm proposing we standardize on n2-highmem-16 nodes for dask workers.

Related

The following issues relate to this smaller and more tightly scoped issue.

• Transition to using only a single node pool for dask-gateway workers (16 CPU, highmem) #2687
• Core node pool revision to minimize cost - towards n2-highmem-2 and r5.large machines #2212
• New default machine types and profile list options - sharing nodes is great! #2121

[consideRatio]

Not much changes remains, closing in favor of an issue that is cloud provider agnostic as I want to convey the same strategy for all cloud providers.