Adding getmempool entry api

[jakesylvestre]

Hi,

As per #908/#905/#1075 I'm currently working on an implementation of the getmempoolentry api in rpcserver and will open a PR once I'm a little further along. I'm a bit confused by some of the mempool storage mechanisms and was hoping someone could point me the in the right direction as far as stuff to implement. I've put together the table below where mempoolTx is s.cfg.TxMemPool.FetchTransaction(rawMempoolTx) and rawMempoolTx is a chainhash.NewHashFromStr of the TxID passed by the user in GetMempoolEntryCmd (PR should clarify this).

name	source	description
vsize	missing in #905, int32(mempoolTx.MsgTx().SerializeSize())	(numeric) virtual transaction size as defined in BIP 141. This is different from actual serialized size for witness transactions as witness data is discounted.
size	int32(mempoolTx.MsgTx().SerializeSize())	(numeric) virtual transaction size as defined in BIP 141. This is different from actual serialized size for witness transactions as witness data is discounted. (0.19.0: (numeric) (DEPRECATED) same as vsize. Only returned if bitcoind is started with -deprecatedrpc=size)
weight	missing in #905, can be computed using GetTransactionWeight and mempoolTx.MsgTx()	(numeric) transaction weight as defined in BIP 141.
fee	mining.TxDesc.Fee possesses this for transactions sent out locally. Transactions sent by others are stored at receive time in bitcoin core, we store this in mining.TxDesc, but this is not returned by FetchTransaction so we'll need a new method here. Going forward, I assume this method has been added when sourcing	(numeric) transaction fee in BTC
modifiedfee	None yet, it looks like bitcoind handles this with an NFee parameter set in the constructor of it's CTxMemPoolEntry class	0.16.0 - (numeric) transaction fee with fee deltas used for mining priority, 0.19.0 - (numeric) transaction fee with fee deltas used for mining priority (DEPRECATED)
time	mining.txDesc.Added	(numeric) local time transaction entered pool in seconds since 1 Jan 1970 GMT
height	mining.txDesc.Height	(numeric) block height when transaction entered pool
descendantcount	None, this is completely unimplemented other than the return type in #905 here, this appears relatively trivial to implement in the same way bitcoind has with it's CalculateDescendants method called by this	(numeric) number of in-mempool descendant transactions (including this one)
descendantsize	None, this is completely unimplemented other than the return type in #905 here, bitcoind implements with GetSizeWithDescendants, like the output above, this appears to be cached by bitcoind requiring a lock we can probably avoid by recomputing	(numeric) virtual transaction size of in-mempool descendants (including this one)
descendantfees	None, this is completely unimplemented other than the return type in #905 here, bitcoind implements with GetModFeesWithDescendants here, like the output above, this appears to be cached by bitcoind requiring a lock we can probably avoid by recomputing	(numeric) modified fees (see above) of in-mempool descendants (including this one)
ancestorcount	None, this is completely unimplemented other than the return type in #905 here, bitcoind implements with GetCountWithAncestors here, like the output above, this appears to be cached by bitcoind requiring a lock we can probably avoid by recomputing	(numeric) number of in-mempool ancestor transactions (including this one)
ancestorsize	None, this is completely unimplemented other than the return type in #905 here, bitcoind implements with GetSizeWithAncestors here, like the output above, this appears to be cached by bitcoind requiring a lock we can probably avoid by recomputing	(numeric) virtual transaction size of in-mempool ancestors (including this one)
ancestorfees	None, this is completely unimplemented other than the return type in #905 here, bitcoind implements with GetModFeesWithAncestors here, like the output above, this appears to be cached by bitcoind requiring a lock we can probably avoid by recomputing	(numeric) modified fees (see above) of in-mempool ancestors (including this one)
wtxid	None, this is missing in the return type of #905 (something that should probably be fixed for RPC compatibiliy)	(string) hash of serialized transaction, including witness data
fees	None, this is missing in #905 and needs to be computed using the methods above for each segment like this	"fees" : {,"base" : n,,(numeric) transaction fee in BTC,"modified" : n,,(numeric) transaction fee with fee deltas used for mining priority in BTC,"ancestor" : n,,(numeric) modified fees (see above) of in-mempool ancestors (including this one) in BTC,"descendant" : n,,(numeric) modified fees (see above) of in-mempool descendants (including this one) in BTC,}
depends	None, this can be computed by checking the pool for each transcaction. In bitcoind, this is computed on the fly here	(array) unconfirmed transactions used as inputs for this transaction

Please note also since #1484 didn't update the changes in #905 to the new version of getmempoolentry

I had no clue where StartingPriority or CurrentPriority came from. There's no reference to these in RPC Doc versions 0.16-0.19 so I checked out the changelog and it looks like these were removed in version 0.15.0 (see changelog). These are no longer returned in any of the RPC methods in bitcoind 0.19.0 and need to be removed in GetRawMempoolVerboseResult as well.