Closes #19891: Bulk operation jobs

[jeremystretch]

Closes: #19891

• Adopt fix for bug No entry point exists to mark a background job as failed #19806 in v4.3.4
• Refactor base bulk edit forms
• Add background_job toggle to BulkEditForm and BulkDeleteForm via BackgroundJobMixin
• Extend BulkEditView & BulkDeleteView to support background jobs
• Move the attachment of a success message to process_request_as_job()

[jnovinger]

Sorry, this has a fair amount of surface area, so wanted to give it some attention while poking at it. Everything seems to work very well. I only noticed one potentially unexpected behavior.

When invoking bulk edit or bulk delete for for objects in a sub-table (think: viewing interfaces of a device, via the device's detail view), you're dumped back in the generic list view for the item type being edited/deleted.

So, I have a switch. I select multiple interfaces from /dcim/devices/<device pk>/interfaces/ and click bulk edit/delete. I then select background job and submit. I get redirected to /dcim/interfaces/.

[jeremystretch]

When invoking bulk edit or bulk delete for for objects in a sub-table (think: viewing interfaces of a device, via the device's detail view), you're dumped back in the generic list view for the item type being edited/deleted.

I think this is actually a regression introduced under #19735; it occurs in the current feature branch as well. I considered tackling it as part of this PR, but it probably requires changes to form controls outside the scope of the associated FR. I've opened bug #19911 to address this separately.