Is your feature request related to a problem? Please describe.
Yes. Retrieving TXs for a wallet with a large transaction history, may result in an unknowably large response. This could cause performance or UX issues for users with lots of transactions. Super users (or exchanges) with thousands or maybe millions of txs one day may have a problem with this API as it exists today.

Describe the solution you'd like
I think the API should allow the requester to constrain the response to a limited number of TXs.

Describe alternatives you've considered
A simple alternative, would be to add count and start_at args to the retrieve_txs() method. In addition to constraining the response to a limited number of results, this will also facilitate pagination. Pagination may be the best solution, when grin super-users or exchanges begin to stress the limits of a wallet with 10Ks/100Ks/1Ms of transactions.

Additional context
Constraints like this will also be valuable/necessary for wallets running in resource limited environments (RaspPi, hardware wallet, etc).

I volunteer to do this work if there is community buy-in around the idea. This would be a breaking change to the API, so it would be nice to coordinate this change with other breaking changes (e.g. #657).