Implement txid plugin to find transaction by hash

[abitmore]

For client application developers who want to query for transaction with a hash directly from the node.

Added 2 API calls:

• get_transaction_by_id ( txid, optional do_not_fetch_the_whole_tx )
• get_transaction_count

Testing how much RAM it will use.

[abitmore]

Reached 12G RAM after

[by size: 20.26259% 14894044656 of 73505127655] [by num: 66.33646% 26550000 of 40023241]

All other plugins are disabled.

I don't think it's good to enable this plugin by default.

[bijianing97]

#1906

[pmconrad]

Is there a specific reason for adding this? IMO keeping TX IDs in RAM is the wrong way. The plugin will be of little use for anyone.

IMO it would be better to add some kind of generic message streaming API that external applications can easily consume, as a common base for ES and other ways to store TX information in an external database.

[abitmore]

There were quite some developers asked for an API to query for transaction info by txid. The same request pops up now and then. We didn't have one because we knew it would consume much RAM if implemented with boost multi-index container, as you said, it's not a good idea. This PR does prove it.

However, if someone needs the feature too badly and have lots of RAM to throw in, this plugin would be helpful. Actually I wrote this code because someone told me that they do need such a feature and "adding RAM is not an issue". I didn't know how much RAM we'll really need before get this done, as mentioned in OP. I don't know whether it's still "not an issue" for them after knowing the numbers.

At least, this PR defined the APIs. In the future if we decide to merge #1906 or implement something alike, we can update the APIs to read data accordingly (if user enabled this plugin, read from RAM; if enabled another plugin, read from elsewhere).

By the way, this is a really simple plugin, can be used by new developers to learn.

[abitmore]

#1957 will do the job. No one will use this. Closing.