Speed up auction metrics (#4155)

# Description
A surprisingly big amount of time in the auction building process is
wasted with metrics.
By far the biggest offender is the function `checkpoint()` which figures
out which orders got filtered out since the last checkpoint. It does it
by cloning the currently alive orders and removing the still alive
orders from that map one by one. All the orders that are left over are
no longer alive.
This regularly incurs an overhead of a couple milliseconds each while
the alternative function `checkpoint_by_invalid_orders()` (which gets
the removed orders passed in) only takes a few microseconds.

Additionally constructing the an `OrderFilterCounter` also take ~5ms
because it clones the original set of orders and counts them already
there.

<img width="1649" height="682" alt="Screenshot 2026-02-13 at 12 29 01"
src="https://github.com/user-attachments/assets/076c6366-d6c5-4376-80a7-222a377812a3"
/>

# Changes
- drop `OrderFilterCounter` in favor of function on the metrics
- from all functions return a list of filtered orders such that we don't
have to do a ton of computations to diff the orders before and after a
filter function
- fixed resulting compile errors in the tests

This technically introduces breaking changes but IMO those are well
worth it:
* we don't populate the gauges once at the start of the process and once
at the end - instead we update individual gauges as we go
* some orders can **technically** be double counted. Since filtering for
banned users, unsupported tokens and invalid signatures happens in
parallel and happens separately the same order can be counted for
multiple things. The orders filtered that way are relatively few and
having the chance that orders fit multiple categories is even lower. On
the plus side if there are multiple things wrong with an order we now
learn about it. Since the exact numbers of filtered orders are not super
interesting anyway one can even consider this a debugging improvement.

Author: MartinquaXD