Between calling destroy_lxc_container and removing the ID from
user.cfg (remove_vm_access) creating a new CT with this ID was
possible. CTs could go missing from pools as a consequence.
unlinking must happen at the very end of the deletion
process to avoid that other nodes use the ID in the meanwhile
Further lock the config after the VM was destroyed with a config lock
named, well, destroyed. This way it's easy to know that the CT was
destroyed but has still the config skelleton and FW, access etc.
stuff possible left over.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>