Transfer history pagination API call

[manuelwedler]

Currently the pagination of the transfer history happens in the frontend. All payment events are queried and then filtered.

Only the events that are displayed should be queried from the backend by using the limit and offset parameters.

[manuelwedler]

I tried to implement this in different ways. The issue is the search functionality that filters the history by a user input. The filtering has to be done in the frontend at the moment, as the current API implementation does not allow a filtering as we would need it. That means that to apply the filtering correctly we need to query more events than are displayed. Every solution I could think of gets overly complicated or has some tradeoffs.

We need a change in the API to implement this properly. I think there are two good solutions to this problem now:

1. We only allow to filter the page by an address. So putting WETH into the search filter would not work anymore but the user could use the autocomplete to set the address of WETH. By that way there can't be more than one token or payment partner address that matches the search filter. For this solution Query all payments with a specific payment partner raiden#6283 would need to get implemented.

2. We change the /payments endpoint to allow filtering for multiple token and payment partner addresses. Now we could get all token and contact addresses that match the search filter and send them in our query.

For both proposed solutions it would be good to have a way to get the total number of payment events that exist for the queried token and payment partner address. So we would know what limit and offset parameters to apply for getting the newest payment events.