Fixing bug that was causing the Indexer to stay busy in cooperative m…

[fulmicoton]

…ode.

Removing the difference between Idle and Processing.
It was originally introduced with the idea of measure how long actors
where busy or idle, but tokio-console does that job very well now.

The code was relying on the enforcement of the non trivial state machine:
calling .idle() in the pause state had no effect for instance.

The real bug however showed up with the following sequence of event:

• indexer drains its queue
• on_drain is called
• indexer "goes to sleep" by putting itself in the Pause state.
• a low priority message is queued into the low priority queue.
• indexer receives a high priority message (Observe is sent every second).
• indexer would go through the loop logic consuming the entire pipeline,
  but only consuming high priority messages. The inbox.is_empty() exit
  condiition is never satisfied, so that this loop would keep going,
  yielding at each iteration, until the Resume Command is received.

This is done on the indexer runtime.
The task would always be busy, but yield all of the time, consuming the
whatever room is available on the thread it is consuming.

Closes #4448

Test

The bug was doing a using yielding loop, so unit testing is a difficult.
I tested locally and on k8s.

A small pipeline of 100KB/s now takes <1% cpu vs 1 full core before.
Outside of merges, indexing 100200kb=20MB on a single node takes 1 cpu instead of 4.
Outside of merges, indexing 1000200kb=20MB on a 10 nodes takes 1 cpu instead of 4.