Post VM instance ID from the Agent as part of the "AgentCanSchedule" request

[stishkin]

Implementing this work item will fix Azure throttling issues when OneFuzz iterates over scalesets in order to find matching Instance Id for a VM, based on a VM ID. Also implementing this removes need for caching Instance IDs in memory cache altogether.

When OneFuzz agent starts up it can get it's own Instance ID by performing following calculation:

Each VM in a scale set also gets a computer name assigned to it. This computer name is the hostname of the VM in the [Azure-provided DNS name resolution within the virtual network](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances). This computer name is of the form "{computer-name-prefix}{base-36-instance-id}".

The {base-36-instance-id} is in [base 36](https://en.wikipedia.org/wiki/Base36) and is always six digits in length. If the base 36 representation of the number takes fewer than six digits, the {base-36-instance-id} is padded with zeros to make it six digits in length. For example, an instance with {computer-name-prefix} "nsgvmss" and instance ID 85 will have computer name "nsgvmss00002D".

source: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-instance-ids

When calling AgentCanSchedule, agent includes instnace ID as part of the message - OneFuzz service saves Instance ID as part of the Node record in the Node Table.

Upgrade path:

• When instance ID is needed to apply scale in protection (or to remove it) - first check the Node table for the instance id. If not there then it is older version of the node, and use current logic to iterate over the scaleset to find the instance id.
• In about 8 days - it is safe to remove "current logic" i.e. caching and scaleset iteration to find the instance id, since all nodes will be upgraded by that time, and will be reporting instance IDs that will be persisted in Node table

AB#41893228

[Porges]

Sent a PR which implements this but including it as part of the AgentRegistration message instead, and the decoding of the computer name to instance ID happens in the server since it's a VMSS-specific thing, so I feel like the knowledge should be there instead of in the agent itself.