Consider consecutive estimator internal errors

[squadgazzz]

Description

From the original issue:

Native prices are an essential part of the auction. That's why the autopilot needs to have a valid native price for all tokens (sold and bought) in an auction. The NativePriceCache has a background task that continuously updates missing native prices.
It obviously caches valid native prices but also responses indicating that no solver has enough liquidity for the requested token. This is done to avoid fetching native prices over and over for tokens that no solver supports.
However, when a solver reports some different error (best example are rate limiting errors) we assume they are just intermittent and re-requesting the native price might work in the future.

The problem is that this logic does not consider the case where a solver always returns an error for a given token while also not other solver is able to produce a good result.
This happened recently where one solver always returned 404 errors because it got shut down on staging. Since no solver was able to produce a price and the logic assume these errors are intermittent we queried the native price for a few tokens over and over again which resulted in a lot more request than usual.

This PR addressed it by introducing a consecutive estimator's internal errors counter. The consecutive error threshold is hardcoded with a value of 5(still a subject of consideration). While a threshold is not reached, the requests remain to be sent to the solver. Otherwise, the cache uses the cached value until it expires using the existing timeout or until another result gets cached. Received recoverable errors don't reset the accumulative errors counter.

How to test

Added a unit test.

Related Issues

Fixes #3159