Fixes #14081: Fix cached counters on delete for parent-child items

[arthanson]

Fixes: #14081

@jeremystretch this will cause one extra db call on delete to an object tracked for a cached counter. The other option would be to save/check the objects to a request-specific queue (like webhooks uses) this code would be less clear but would obviate the need for another DB call. As it is just on delete, not sure if the extra DB call is a problem here?

The root issue is when you have a parent-child relationship (like inventory items) using MPTT and you do bulk-delete on them you wind up getting three delete signals instead of two:

1 for the child object being deleted from the cascade delete of the parent
1 for the parent object
1 additional one for the child object (not cascade deleted)

As can be seen from below, all the params to post_delete are the same except for the instance and origin not matching for the child delete case, but this is needed if you aren't doing bulk_delete and just delete the parent item:

sender: <class 'dcim.models.device_components.InventoryItem'> instance: invc1 instance_pk: 40 origin: inv1 parent_pk: 88, parent_model: <class 'dcim.models.devices.Device'> kwargs: {'signal': <django.db.models.signals.ModelSignal object at 0x101ad9510>, 'using': 'default'}
sender: <class 'dcim.models.device_components.InventoryItem'> instance: inv1 instance_pk: 39 origin: inv1 parent_pk: 88, parent_model: <class 'dcim.models.devices.Device'> kwargs: {'signal': <django.db.models.signals.ModelSignal object at 0x101ad9510>, 'using': 'default'}
sender: <class 'dcim.models.device_components.InventoryItem'> instance: invc1 instance_pk: 40 origin: invc1 parent_pk: 88, parent_model: <class 'dcim.models.devices.Device'> kwargs: {'signal': <django.db.models.signals.ModelSignal object at 0x101ad9510>, 'using': 'default'}

Because of the way MPTT is doing the delete the instance between the calls is actually two different instances, so I tried directly setting _previously_deleted inside post_delete on the instance, but it isn't there on the second call.

This causes an additional DB call when deleting a cached_counted item. The other way I thought of potentially handling this was to store the deleted ids in a request queue (like webhooks code uses) and check if it is in the queue (already deleted) before decrementing the counter. The queue would need to be cleared at the end of the request. However this makes the code less-clear and splits the queue init and handling.