CA-391880: Update related field 'groups' of VM when destroying VM group.

[BengangY]

In VM anti-affinity datamodel PR, there is many-many relation between VMs and VM groups. When changing the VM.groups manually, the VM_group.VMs will be updated automatically. But when removing a VM group, the VM.groups will not be updated automatically. This commit aims to update VM.groups for all VMs in a VM group when it is being removed.

[minglumlu]

there is many-many relation between VM and VM group.
-> there is many-many relation between VMs and VM groups.

When removing a VM, or updating VM.groups, the VM group will update VM_group.VMs automatically.
-> When changing the VM.groups manually, the VM_group.VMs will be updated automatically.

But if removing a VM group, VM.groups will not update automatically.
-> But when removing a VM group, the VM.groups will not be updated automatically.

I didn't find a method to update it automatically. So I add some codes to update VM.groups when removing a group.
-> This commit aims to update VM.groups for all VMs in a VM group when it is being removed.

[gangj]

In VM anti-affinity https://github.com/xapi-project/xen-api/pull/5546, there is many-many relation between VMs and VM groups. When changing the VM.groups manually, the VM_group.VMs will be updated automatically. But when removing a VM group, the VM.groups will not be updated automatically. This commit aims to update VM.groups for all VMs in a VM group when it is being removed.
Would you please add this as the description of the code commit? It will make the code commit more clear.

I didn't find a method to update it automatically. So I add some codes to update VM.groups when removing a group.
I think this is the required thing to do, as we can find the same for the other relationship:
((_pci, "attached_VMs"), (_vm, "attached_PCIs"))
vm is removed from pci.attached_VMs: Db.PCI.remove_attached_VMs when needed, for example, when vm is destroyed.

[github-actions]

pytype_reporter extracted 50 problem reports from pytype output

.

You can check the results of the job here

[robhoes]

The attached_PCIs is the only other example if a many/many relation in the datamodel that I can think of. And I recall problems with this then-new type of relation, which we didn't understand at the time. Ideally, the database should be updated automatically, and I think that setting one side of the relation does indeed correctly update the other side. But there may be a problem that the fields are not updated properly when objects are being deleted.