Add amount_by_sender query to storage to return transaction amounts and denominations grouped by sender address

[aubrika]

Closes #3068

[cronokirby]

I think this is what we want, although I'm not sure if the GROUP BY in the query does what we want it to do. I think the code should work without it.

[cronokirby]

What does GROUP BY do for Blobs?

[aubrika]

Without grouping by the address, you won't filter out asset amounts for the other addresses, because the JOIN does not otherwise take this into account/is not unique to the address. I initially thought the same but testing revealed the need to specify a specific grouping to return the appropriate values per address.

[cronokirby]

Have we tested the case where you send the exact same amount twice? I think the GROUP BY might clobber that

[cronokirby]

Like my understanding of how GROUP BY works without aggregation functions is that it's like doing SELECT DISTINCT, which would have this undesired behavior when you see a repeat of (return_addr, denom, amount)

[hdevalence]

Why do we want this to do the summarization internally? Wouldn't it be more flexible to have something like

notes_by_sender(&self, return_address: &Address) -> Result<Vec<SpendableNoteRecord>>

and then let the caller figure out how to interpret the results?

[cronokirby]

Well, we want the signature to be such that the output contains all the addresses, rather than us having to figure out what addresses we need to pass into the function. This would be a return type of like Iterator<(Address, SpendableNoteRecord)> with the address appearing multiple times.

While this might be useful in more situations, right now the single consumer of this API just wants the total amount received. I think we can just punt the issue of providing a more generally useful version of the API once there's more consumers of that API.

[cronokirby]

Okay actually I think implementing Henry's suggestion makes sense now :p

[hdevalence]

The key point is that for the coordinator we're making this API for, we only ever want to query for single, specific addresses, and we don't want to have to scan through a potentially unbounded amount of data to run the query.

[cronokirby]

Looks good to me!