Eliminate usage of bulk_create() and bulk_update() methods outside of tests and migrations

[jeremystretch]

Proposed Changes

While we've generally avoided the use of bulk_create() and bulk_update() for the bulk creation and manipulation of objects due to the caveats associated with their use (namely not triggering the post_save signal), they are still used in a few areas within NetBox. The goal of this issue is to eliminate any usage of these methods, excluding within tests and migrations where specifically needed to ensure optimal performance.

Justification

As calling bulk_create() or bulk_update() does not generate a post_save signal for each of the objects affected, this escapes change logging and (in NetBox v3.4) search indexing. Although calling save() on each instance individual will impose a performance penalty, it ensures that each instance is subject to the appropriate background workflows. (This was initially called out here by @kkthxbye-code.)

[arthanson]

bulk_create used in:

• netbox/dcim/models/devices.py
• netbox/search/backends.py

bulk_update used in:

• netbox/dcim/models/devices.py
• netbox/extras/models/customfields.py
• netbox/ipam/signals.py
• netbox/ipam/utils.py

[jeremystretch]

The goal of this issue is to eliminate any usage of these methods

Rather than eliminating their usage, which would incur significant performance penalties when performing certain operations, we could instead manually trigger the post_save signal for each object after the bulk operation is run. I'm a little hesitant to commit to this approach as it alters Django's default behavior, however it might be reasonable for our purposes. I'm going to put in a PR to test.

[jeremystretch]

The hybrid approach I mentioned above seems to save a substantial amount of time compared to completely removing the bulk calls (despite still being far slower than the current implementation, which does not support change logging). I've merged PR #10900 using this approach and will test during the v3.4 beta release. Should any serious issues with this approach surface, we'll revert to the approach in PR #10780.