Ability to "merge" transactions

[letehaha]

Implementation detail

Once the user decides to merge transactions A,B,C we need to do the following things:

1. Validate that they have the same flow – we cannot merge income with expense, only same-type. Or not? If not, then we can implement a "refund" functionality when income overrides expense so that stats are not affected. But that might heavily degrade SQL query performance.

2. Generate a unique mergeId and add it to the Transaction model (need to update DB structure).

3. Do the actual merge. Create a new "merge" transaction or just keep them as is, and when API returns transactions list, also include all transactions with the same mergeId, so it can be merged. Or merge it on the API side and simply return a synthetic transaction? Might be bad from API design and DX experience since it adds business logic to the response.

The possible flow:
When merging, "archive" all related transactions, add them mergeId to be able to find all related txs, and create a brand-new transaction that will represent the result of the merge. That way we don't need to store olds values in some new way. Also it will be super easy to edit the list of transactions used in merge. That means we can still implement the "refund" functionality. Merging might be possible between different accounts, but then to which account a new transaction should be added?