fix: avoid reward redemption crash via buffer refactor

[iProdigy]

Closes #2432
Closes #3942

Supersedes #4942

Inspired by #4943 (review)

Rewrites self-destructing signal usage (that suffered from inadequate value forwarding & use-after-free) with buffer approach that holds redemptions without a corresponding reward until a relevant pubsub message arrives

[Nerixyz]

Works for me and is easier to debug. 👍

[Nerixyz]

Do we use the aspect that this is a circular buffer? This seems like it could be a std::vector.

[iProdigy]

This has the advantage of automatically dropping the oldest queued redemptions when many new redemptions are being queued

Imagine a redemption (for an unknown reward) occurs while pubsub is disconnected. Later, the reward is deleted and pubsub reconnects. With a vector, we'd never delete this redemption. With the buffer, we place a limit on how many outstanding redemptions can be held in memory. (this can be replaced with vector but erase(begin) is $O(n)$ for vector while circular buffer just overwrites the element in the first position in $O(1)$ time)

[iProdigy]

Since deletions can happen in the middle of the collection, perhaps we should use std::list instead to avoid copying elements (and can easily implement max size logic ourselves)

[iProdigy]

Switched to std::list in 5010223

In reality, most of the operations are (1) add element to empty collection and (2) remove singular element from collection (rendering it empty). This is $O(1)$ with std::list but we may want to consider whether std::vector has a small memory footprint here (if we prefer to optimize for the typical use case rather than edge cases)

Edit: when there are multiple elements in the collection, we have to iterate to determine which elements to remove. this is likely faster for vector and buffer due to contiguous memory allocation

[iProdigy]

actually buffer may be best (i overestimated copying cost): https://www.codeproject.com/Articles/1185449/Performance-of-a-Circular-Buffer-vs-Vector-Deque-a / https://www.codeproject.com/Articles/340797/Number-crunching-Why-you-should-never-ever-EVER-us

[pajlada]

This looks good to me, and is easier to reason about 👍 Thank you for taking the time to dig into this!

[pajlada]

@Nerixyz @iProdigy if either of you could take a peek at the comment I added in 1458b0b that would be good - once that's done I'll merge this in

[iProdigy]

Comment looks good to me!

[Nerixyz]

The type name ChannelPointReward is a bit confusing. It suggests that we get the reward definition while we actually get a redemption that happens to include the reward definition. But that's for a future PR.