Allow generate_block() to accept Transaction IDs along with encoded signed transactions

[alfiedotwtf]

With #755, generate_block() allows the caller to create blocks via RPC. However, they will need to supply encoded signed transactions. This issue is a note to replicate Bitcoin's functionality, allowing the caller to accept transactions or transaction IDs (which refer to transactions in the mempool).

See #755 for more detail.

[TheQuantumPhysicist]

@alfiedotwtf Can you please check what's the status with this? You said there's something to be covered here, but I think this may be half-done.

[alfiedotwtf]

I think we have a solution, so now it's just a prioritization issue now.

Copying from GItlab's issue:

@alfiedotwtf :

During yesterday's meeting, it was decided that to prevent the issue of double spend and other potential issues, the supplied transaction hex should be sent through a transaction verifier before calling collect_tx()...
But before I do this change, I want to confirm something - after going through the transaction verifier code, I'm not sure which TransactionSourceForConnect the supplied transaction hex should fall under for the connect_transaction() call - There's currently TransactionSourceForConnect::Chain and TransactionSourceForConnect::Mempool, neither of which feels right to sneak these transaction hex into. So in this case, should I add a TransactionSourceForConnect::Provided arm?

@iljakuklic :

I would say Mempool is more appropriate here out of the two. Maybe it could be renamed to something more descriptive that covers both cases. It basically says this is a candidate for inclusion in the next block (as opposed a transaction already included in a block).

[iljakuklic]

Closing this, mostly implemented in #1270. Remaining issues described in #1273