Comment 2 for bug 1989651

Given that Bionic/Focal remove the /var/lib/cloud/instance/obj.pkl cloud-init calls find_source to rediscover the Azure datasource and persist a discovered datasource cache by crawling get_data due to the event BOOT_NEW_INSTANCE in order to persist said obj.pkl.[1]

The DatasourceAzure is also configured to run get_data to update network config per EventType.BOOT as well[2] during apply_network_config calls. This is an event update which is only checks whether the "apply_network_config" semaphore has run on this boot, and if the datasource supports per EventType.BOOT configuration.[2] It doesn't currently have visibility to whether get_data ran for another event reason (BOOT_NEW_INSTANCE) which is unique to a condition introduced by Azure's removal of obj.pkl triggering the find_source call again.

When init-local ties to run apply_network config, and Azure is set to allow EventType.BOOT both conditions will be true in [2] and result in that 2nd get_data call.

To avoid this waste, we could either:
 1- make `update_metadata_if_supported` aware that both EventType.BOOT_NEW_INSTANCE, and EventType.BOOT fired by preserving the per boot events that have already been processed so we don't invoke a 2nd BOOT-related event when another has already run get_data
 2. make `update_metadata_if_supported` aware of last get_data and if it happened already during boot, avoid calling get_data a 2nd time during the same boot
 3. avoid calling update_metadata_if_supported for EventType.BOOT in apply_network_config if we have called the method due to an EventType.BOOT_NEW_INSTANCE

[1] https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/__init__.py#L940
[2] https://github.com/canonical/cloud-init/blob/main/cloudinit/stages.py#L903