Closes #12135: Prevent the deletion of interfaces with children

[jeremystretch]

Fixes: #12135

• Change on_delete behavior for parent field Interface and VMInterface from SET_NULL to RESTRICT
• Update UI & API views to cleanly handle RestrictedError exceptions (the same way as ProtectedError)
• Update BulkDeleteView to perform all deletions within an atomic transaction
• Add get_bulk_update_queryset() and get_bulk_destroy_queryset() methods to API viewset mixins to allow overriding the default querysets for bulk operations
• Update the bulk deletion querysets for device & VM interfaces to order objects by parent, to ensure children are deleted before their parents
• Add tests for deleting parent interface individually as well as both parent and child interfaces, for both devices and VMs

[kkthxbye-code]

Feedback from the issue thread:

[with this PR you] can delete a device if it doesn't have any virtual interfaces but not if it has any. Seems inconsitent and confusing. Why are child interfaces more important than parent interfaces when deleting an entire device?

The same applies for modules and while not sure how common; entire racks/sites as well.

[jeremystretch]

[with this PR you] can delete a device if it doesn't have any virtual interfaces but not if it has any.

@kkthxbye-code Could you please elaborate on your reason for downvoting this PR? Is your opposition limited to the need to work around this limitation when deleting devices/VMs?

[kkthxbye-code]

Is your opposition limited to the need to work around this limitation when deleting devices/VMs?

Mostly yes. If it can be limited to only applying when deleting the parent interface, I think it at least not majorly impacts usability.

Do note that the current implementation also breaks bulk deletion of interfaces if any of the devices selected has a parent and the parent is also included in the list.

[jeremystretch]

I think we can use RESTRICT instead of PROTECT here to still allow the automatic deletion of a parent interface when the parent itself is being deleted via a cascading deletion.

[jeremystretch]

We can mostly work around the bulk deletion issue by ordering interfaces by parent (nulls last), to ensure all child interfaces in the list are deleted first. However, this doesn't address the (presumably) rare case where there are multiple levels of child assignments (e.g. A -> B -> C). (The workaround for the user in this case would be to manually delete the grandchildren first.)

Another tact would be to sort interfaces to be deleted in reverse order by primary key, as we'd typically expect child interfaces to always be created after their parents. However, there exists a corner case with this approach too, where a new interface is created and then an existing child interface is assigned to it.

Combining both approaches (by overriding get_queryset() on the appropriate views might be sufficient, but I'm open to other ideas.