API Bulk-Create of Devices does not check Rack-Space in its own context

[moonrail]

NetBox version

v3.0.6

Python version

3.9

Steps to Reproduce

1. Create Rack with 42U
2. Create Device-Type with Height of 2U
3. POST /dcim/devices/:

[
  {
    "device_role": 1,
    "device_type": <your_id>,
    "site": 1,
    "rack": <your_id>,
    "face": "front",
    "position": 1
  },
  {
    "device_role": 1,
    "device_type": <your_id>,
    "site": 1,
    "rack": <your_id>,
    "face": "front",
    "position": 2
  }
]

Expected Behavior

A ValidationError with >400 HTTP Status, as both Devices overlap each other in the Rack.

Observed Behavior

API returns 201 HTTP Status and both Devices are there.
Further Handling other than deleting them or moving them to another position is not possible.
This also breaks SVG-rendering of Racks:

  File "/opt/netbox/netbox/dcim/api/views.py", line 218, in elevation
    drawing = rack.get_elevation_svg(
  File "/opt/netbox/netbox/dcim/models/racks.py", line 392, in get_elevation_svg
    return elevation.render(face, unit_width, unit_height, legend_width)
  File "/opt/netbox/netbox/dcim/svg.py", line 192, in render
    for unit in self.merge_elevations(face):
  File "/opt/netbox/netbox/dcim/svg.py", line 156, in merge_elevations
    elevation = self.rack.get_rack_units(face=face, expand_devices=False)
  File "/opt/netbox/netbox/dcim/models/racks.py", line 313, in get_rack_units
    elevation[device.position]['device'] = device
KeyError: 2

This Issue does not occur on API POST /dcim/devices/ with only one Device.
This Issue does not occur in Frontend-Import-View for Devices.
In both these circumstances the transaction is rolled back due to insufficient Space.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

[jeremystretch]

We'll probably have to sit on this until we figure out what the implementation of #51 looks like.