Speed up auction metrics

[MartinquaXD]

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.

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.

[gemini-code-assist]

Code Review

This pull request refactors the auction metrics to improve performance by removing the OrderFilterCounter and its inefficient checkpoint method. The new approach has filtering functions return removed orders directly, which is a significant improvement. My review focuses on the correctness and performance of the new implementation. I have one suggestion to further optimize a new metrics helper function, which aligns with the PR's performance goals and does not conflict with any established rules.

[jmg-duarte]

nit: the let mut later on was useful to pinpoint where the mutability need started

[MartinquaXD]

Hmm, not sure this argument makes sense to me. Shouldn't we by that logic make the orders immutable again afterwards?
Reverted back to the original mut since this is not a hill I want to die on but it fees like there should be a somewhat obvious rule one could follow regarding that.