tokens service: rework PruneInvalidUnspentTokens

[adecaro]

From @alexandrosfilios on #975 (comment)

This buffer size doesn't look very correct. I guess your limitation is the chaincode? We should pass all tokens and then the chain code should split them into batches and return the response. 3 reasons:

If we have a different implementation that supports bigger chunks, we cannot leverage it.
All subsequent calls (e.g. SpentIds, deleteTokens) cannot delete faster.
It is not clear what the reason, i.e. limitation is. Is it the cc?
The APIs should be agnostic to the limitations of the implementation.

I'll add more information here: The message sent to the chaincode has a limit of 100MB. This is the reason the buffer was introduced. But, for instance, I'm also noticing that PruneInvalidUnspentTokens might keep the iterator opened for too long. It would be better to have an implementation that doesn't require this. Notice also that the amount of unspent tokens is huge, therefore the PruneInvalidUnspentTokens function should be called only when the system is under very low load.