Chunk /gettransactions to avoid hitting restricted RPC limit

[tobtoht]

Fixes the following issue when mempool contains more than 100 new transactions when connected to a restricted node:

Error calling gettransactions daemon RPC: r 1, status Too many transactions requested in restricted mode

@selsta

[jeffro256]

Could we detect if the daemon is in restricted mode and chunk accordingly, as opposed to defaulting to the (rather low) value of 100?

[plowsof]

i think this is what happens already here (on the server side at least)

monero/src/rpc/core_rpc_server.cpp

Line 888 in 9750e1f

if (restricted && req.txs_hashes.size() > RESTRICTED_TRANSACTIONS_COUNT)

[jeffro256]

Right, but I mean but if the daemon is in unrestricted mode, then we can ask for more at once (what the old code was doing), which would definitely reduce overhead if/when the mempool gets to be the size of (for example) Bitcoin's with >1000 txs per block

[selsta]

LOG_PRINT_L0("Expected " << txids.size() << " tx(es), got " << res.txs.size());

should this log message be updated? Maybe to something like

LOG_PRINT_L0("Expected " << n_txids << " out of " << txids.size() << " tx(es), got " << res.txs.size());

Because otherwise the log is a bit confusing.

2022-06-20 13:47:25.050	     0x1051b8580	DEBUG	wallet.wallet2	src/wallet/wallet2.cpp:3173	asking for 5 transactions
2022-06-20 13:47:25.098	     0x1051b8580	TRACE	net	contrib/epee/include/net/net_helper.h:460	READ ENDS: Success. bytes_tr: 5134
2022-06-20 13:47:25.098	     0x1051b8580	TRACE	net.http	contrib/epee/include/net/http_client.h:648	http_stream_filter::parse_cached_header(*)
2022-06-20 13:47:25.098	     0x1051b8580	DEBUG	wallet.wallet2	src/wallet/wallet2.cpp:3187	Got 1 and OK
2022-06-20 13:47:25.098	     0x1051b8580	WARNING	wallet.wallet2	src/wallet/wallet2.cpp:3226	Expected 59 tx(es), got 5

Adding the remaining tx count would also be nice but might make the log message too complicated.

[jeffro256]

In reply to @selsa:

To piggyback off of this, should this log statement be put inside the loop now since there are now multiple requests which could each individually go wrong?

[selsta]

@jeffro256 it is already in the loop, or am I misunderstanding your suggestion?

[jeffro256]

Oh you're right, I read my brackets wrong, it is inside the for loop

[selsta]

Code reviewed and tested.