Commit 0b70117 ("AKS: Fix dynamic reconfiguration of bridge mode") and
preceding commits would modify an internal state file of the azure-vnet CNI
plugin. This is potentially dangerous, because:

- azure-vnet uses a lockfile to coordinate access to this state file between
  independent invocations.
- The format of the state file is not controlled by us and subject to change.
- How this state file is used can change between versions of azure-vnet.

After investigating some reports of connectivity issues, it turns out that:

- Modifying the state file directly isn't necessary. azure-vnet obeys the mode
  it's given in its CNI configuration, regardless of the mode recorded in the
  state file.
- Changing the mode directly _in the state file_ from `bridge` to `transparent`
  causes azure-vnet to forget cleaning up static ARP entries for deleted Pods
  that were previously created in bridge mode before Cilium was deployed.
  This can cause addresses of Pods previously scheduled on the node to become
  unroutable on said node.
- Waiting for the state file to appear causes a deadlock on newly-created nodes
  in a cluster where Cilium is already running, for example, when scaling out
  a node pool. azure-vnet only creates the state file when it gets its first
  CNI `ADD` event, which will never happen with the CNI configurations Cilium
  installs.

Signed-off-by: Timo Beckers <timo@isovalent.com>