Add filtering capability to parity_pendingTransactions (issue 8269)

[lamafab]

Hi

This pull request adds filtering capabilities for parity_pendingTransactions, as requested in issue #8269.

Changes

• MinerService now has a new ready_transactions_filtered method, which can filter transactions by hash, sender or receiver.
• The regular ready_transactions method wraps over the filter, therefore ready_transactions_filtered can be called directly from the RPC interface without having to adjust code through the whole codebase.

Considerations
I'm having slight trouble testing the code; ready_transactions (the original implementation) always returns two pending transactions on me, never more. This makes testing inconvenient. It might be related to a detail in the test miner that I'm missing, basing my assumption on this method description:

/// Get a list of all ready transactions either ordered by priority or unordered (cheaper).
///
/// Depending on the settings may look in transaction pool or only in pending block.
/// If you don't need a full set of transactions, you can add max_len and create only a limited set of
/// transactions.

If someone can point me in the right direction I can write some complete test cases (so far, NO testing is being done).

See fn filter_pending_transactions_by_tx_hash() in ethcore/src/miner/miner.rs for more.

Any feedback is welcome!

[parity-cla-bot]

It looks like @lamafab signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[tomusdrw]

Looks good as a starting point, I think I'd go one step further and make the implementation more complete in terms of possible options to filtering but also to avoid breaking backward compatibility (the preoposed filtering object could be made optional with a some default value).

I'm having slight trouble testing the code; ready_transactions (the original implementation) always returns two pending transactions on me, never more.

That's because RPC tests are not using the real MiningService, but rather one for tests.
It would be best to test the serialisation/deserialisation in RPC tests, but the filtering logic deserves a separate test in miner module.

[ascjones]

@lamafab needs merging with master

[lamafab]

@tomusdrw @ascjones How quickly do those changes need to be implemented? I'm currently going through exam week, but I can complete this PR, soon. However, I can not guarantee on exactly when...

Regarding testing: I will skip the direct MiningService tests and use the RPC API, as I did in an other PR.

[lamafab]

@tomusdrw @ascjones Alright, I did it! The unified FilterOptions are now implemented in this PR.

pub struct FilterOptions {
    pub sender: FilterOperator<Address>,
    pub receiver: FilterOperator<Address>,
    pub gas: FilterOperator<U256>,
    pub gas_price: FilterOperator<U256>,
    pub value: FilterOperator<U256>,
    pub nonce: FilterOperator<U256>,
}

pub enum FilterOperator<T> {
    Any,
    Eq(T),
    GreaterThan(T),
    LessThan(T),
    ContractCreation, // only used for `receiver`
}

What this PR contains:

• The parity_pendingTransactions RPC API can take optional filter operators like the following:

    {
        "sender": {
            "eq": "0x5f3dffcf347944d3739b0805c934d86c8621997f"
        },
        "gas": {
            "gt": "0x493e0"
        }
    }

• Since not all operators can be used equally on each filter, the allowed/disallowed operators are caught during the deserialization process with a custom implementation of Deserialize (those tests are included in the same location where FilterOptions is defined).

What's missing

• One could argue that there should be GreaterEqualThan and LessEqualThan operators.
• While there are deserialization tests, there are no logic tests for the filtering. @tomusdrw I did a code base search and could not find a lot of useful information regarding testing that API (there are some very simple/oversimplified tests). Can you tell me where those logic tests should be placed and what testing data I should use (or to be more specific: how should the RPC API test server be created?). I can hardly use Gitter during the workday, so I'd appreciate it if you could give me some advice here.

Thank you very much (and for the patience!)

[tomusdrw]

Awesome work! Only few small nits.

[tomusdrw]

❤️

[seunlanlege]

Amazing work 🤝

[seunlanlege]

Beautiful work here.

[tomusdrw]

lgtm

[ascjones]

👀

[lamafab]

Thanks for the nice feedback, everyone. I've added some very small changes (like adding a newline at the end of the file as @seunlanlege suggested).

EDIT: Looks like the failed CI tests are not related to my changes... (?) Last time this happened too, I remember restarting the CI tests solved the issues.