iris: Bypass the BO cache when allocating buffers for aux map tables

+@keithp

When freeing a buffer, we may return a non-idle buffer to the cache, which means we cannot unmap aux entries at that time. Instead, we defer unmapping the stale aux entry until we reuse a BO from the cache.

Unfortunately, this can lead to a recursive locking issue:

1. intel_aux_map_add_mapping wants to set up a new aux entry

   It takes the intel_aux_map_context::mutex lock, then calls:

   add_mapping -> get_aux_entry -> add_sub_table -> add_buffer -> intel_aux_map_buffer_alloc -> iris_bo_alloc

2. iris_bo_alloc tries to allocate a BO from the cache, doing:

   alloc_bo_from_cache -> intel_aux_map_unmap_range -> intel_aux_unmap_range

   ...which then tries to take the intel_aux_map_context::mutex lock. But it is already locked.

One solution would be to rework the aux map handling code to allocate BOs without holding its lock, but that looks to be painful. Another is to make the lock recursive, but we try and avoid that. A third option wuold be to add a BO_ALLOC flag that makes alloc_bo_from_cache skip any buffers with aux_map_address != 0 so we don't have to unmap, making the less cache effective but fixing the recursive lock.

A fourth option is to simply bypass the BO cache altogether for the buffers that hold the aux map itself. Allocating new BOs for the aux tables should be relatively rare, so there's probably not a lot of benefit in using the BO cache.

Closes: #5191 (closed)