RPC Server: pushTransaction and pushHighPriorityTransaction methods broadcast the transaction

[Eligioo]

What's in this pull request?

By only pushing the transaction into the local mempool, the transaction never gets adopted if the node itself isn't an elected block producer.

This fixes #3131.

Pull request checklist

• All tests pass. The project builds and runs.
• I have resolved any merge conflicts.
• I have resolved all clippy and rustfmt warnings.

[sisou]

I'd rather this get fixed with mempool syncing (#2832).

[Eligioo]

I'd rather this get fixed with mempool syncing (#2832).

The goal of PR #2832 is for nodes that just reached consensus get an idea of what the current mempool landscape is it in that moment in time and try to acquire as much of that state. It's not a mechanism to keep mempools in sync in between nodes forever as the mempool in general is an unsynced component. Therefore that PR isn't going to fix #3131.

As stated in the PR description, the Mempool Syncer terminates itself after a fixed amount of time and from there on the node relies on broadcasts done over the network in order to acquire new transactions.

[sisou]

Then I have the same feedback as JD: The push* methods should push to local mempool first, and then only if it succeeded, broadcast to other peers, too. Because the push* methods are the only way to see if a transaction is currently valid - just broadcasting does not provide any feedback on tx validity.

[Eligioo]

@sisou yes I realised the distinction later on too. Basically now in this PR sendRawTransaction and push* have become exactly the same. Will update it.

[jsdanielh]

LGTM