Request filtering should have an optional timeout

[AndrejMitrovic]

Currently the filter Control API is used like so:

node_1.filter!(node_1.putTransaction);
node_2.putTransaction(...);  // triggers gossiping to node 1's putTransaction
Thread.sleep(500.msecs);
node_1.clearFilter();  // after this point the retry mechanism of a node could make the request succeed

However this has a crucial assumption: that the putTransaction of node_2 is an asynchronous call. If it's not, then the main thread will block, node_2 will have its putTransaction request fail after a number of retries, and by that point the node_1.clearFilter call in the main thread will be too late.

It makes more sense to make this timeout built-in into Localrest, to make it usable with blocking APIs. The new code (assuming putTransaction is now blocking) would look like:

node_1.filter!(node_1.putTransaction, 500.msecs);
node_2.putTransaction(...);
// now check if gossiping succeeded, or if max retries were reached

[MichaelKim20]

I have three questions.

1. Can multiple pairs of filtered 'method and timeout' register?
2. If the filter is registered and a clearFilter() was received before the timeout period, is the filter valid?
   Does timeout have a bigger priority than ClearFilter()?
3. Or is the filter automatically turned off after the time limit?

[AndrejMitrovic]

When I opened this issue, I had a talk with @Geod24. The conclusion was that we probably don't need this feature. So I would ignore this issue for now until we re-visit it later @MukeunKim.