potential message loss due to queue filtering

[moshe-blox]

Since we've changed the filtering mechanism recently, and maybe even prior to that, there's the theoretical issue of a consumer refusing to pop certain messages because the Runner never gets to a certain state where it wants these messages, and therefore the queue grows bigger and bigger until it starts dropping messages, potentially even ExecuteDuty messages.

We should examine if our codebase has this issue in practice, and if so maybe we should consider clearing messages that are no longer relevant once the queue hits capacity.

Additionally, we should add unit tests for the various real-world scenarios that occur with message filtering. These tests should be in committee_queue_test.go and invoke the exact same filtering logic as Committee does.

[y0sher]

I think thorough testing to the queue prioritization flow will help us be relaxed about this.