Buster install from scratch fails on `puppet agent --test` run otherwise.

```
Notice: /Stage[main]/Profile::Icinga2::Apt_config/Apt::Source[icinga-stable-release]/Apt::Key[Add key: F51A91A5EE001AA5D77D53C4C6E319C334410682 from Apt::Source icinga-stable-release]/Anchor[apt_key F51A91A5EE001AA5D77D53C4C6E319C334410682 present]: Dependency Apt_key[Add key: F51A91A5EE001AA5D77D53C4C6E319C334410682 from Apt::Source icinga-stable-release] has failures: true
Warning: /Stage[main]/Profile::Icinga2::Apt_config/Apt::Source[icinga-stable-release]/Apt::Key[Add key: F51A91A5EE001AA5D77D53C4C6E319C334410682 from Apt::Source icinga-stable-release]/Anchor[apt_key F51A91A5EE001AA5D77D53C4C6E319C334410682 present]: Skipping because of failed dependencies
Warning: /Stage[main]/Profile::Icinga2::Apt_config/Apt::Source[icinga-stable-release]/Apt::Setting[list-icinga-stable-release]/File[/etc/apt/sources.list.d/icinga-stable-release.list]: Skipping because of failed dependencies
```

Since the nodes were migrated to buster, i manually edited the local
terraform.tfstate (json) file to use the new template-debian-10 node:

```
sed -i 's/"template-debian-9"/"template-debian-10"/gi' terraform.tfstate
```

In order to avoid terraform trying to destroy and recreate the existing nodes.

```
journal0_summary =
hostname: journal0
fqdn: journal0.internal.staging.swh.network
network: ip=192.168.128.10/24,gw=192.168.128.1 macaddr=1E:98:C2:66:BF:33
```

Related T1875

```
vault_summary =
hostname: vault
fqdn: vault.internal.staging.swh.network
network: ip=192.168.128.9/24,gw=192.168.128.1 macaddr=16:15:1C:79:CB:DB
```

```
deposit_summary =
hostname: deposit
fqdn: deposit.internal.staging.swh.network
network: ip=192.168.128.7/24,gw=192.168.128.1 macaddr=9E:81:DD:58:15:3B
```

```
webapp_summary =
hostname: webapp
fqdn: webapp.internal.staging.swh.network
network: ip=192.168.128.8/24,gw=192.168.128.1 macaddr=1A:00:39:95:D4:5F
```

Terraform will refuse to name another node the same (even on different
hypervisor).
That's for the best.

Starting the name at 0 is more consistent with other nodes anyway.

32G is a bit short for the dbs.
100G as well but we'll see for now.

```
scheduler0_summary =
hostname: scheduler0
fqdn: scheduler0.internal.staging.swh.network
network: ip=192.168.128.4/24,gw=192.168.128.1 macaddr=92:02:7E:D0:B9:36
```

https://www.terraform.io/docs/configuration-0-11/locals.html

Related T1875

Related T1875

Add the ssh way which is neater than the proxmox ui.

Default ip is also now 192.168.100.199 which should be free

This provisions the storage node and for the first time, will trigger a puppet
run. This puppet run will install the storage's role including. Its network
paquets coming through the gateway to access everything.

Related T1785
Depends on D1796

Related D1762

This provisions the node and for the first time, will trigger a puppet run.
This puppet run will install the gateway's role including the routes back/forth
between production network and the staging network.

Related T1785
Related T1874

We will build debian vms (oldstable/stable) from a template with some basis
already set-up to avoid repeating those actions for new provisioned vm.

This action is needed to be once in a while (every debian migration to new
stable for example). Still, this is worth documenting/scripting to ease
reproducibility.

Related T1785

Related T1784

This allows to enhance the default terraform install tool with a proxmox
plugin. Allowing to manage the proxmox infrastructure within text files.

Related T1785
Related T1720

Related T1716

This bunch of if...elif...fi is there to reproduce the way the
resource_group and nodename are currently built in the azure infra.

So that we can use those script instead of clicking in the portal ui.

We will either need to:

- factorize that snippet part at some point (which is duplicated in
  add-disk, create-vm and here so far)

- rename our resources in the azure portal