sdk: refactor notification streams and add opt-in receiver gap reporting

[yukibtc]

Description

Replaces #1482

CC @erskingardner

Checklist

• I followed the contribution guidelines
• I updated the relevant CHANGELOG.md (if applicable)
• I understand and can explain all code in this PR

[codecov]

Codecov Report

❌ Patch coverage is 97.54098% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
nostr-sdk/src/stream/notification.rs	97.05%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[yukibtc]

An alternative to NotificationStream::with_gaps may be to use NotificationStream::with_errors, which would return something like Result<T, NotificationStreamError> (for now with just a Lagged variant).

[TheAwiteb]

How can this be useful? For example, when I know that I missed 7 events, what should I do? Should I have a general receiver that caches events, so I can ask it for the missed ones? Or should I re-subscribe? Or just log a warning so I try to handle events faster?

[TheAwiteb]

ACK

[yukibtc]

How can this be useful? For example, when I know that I missed 7 events, what should I do? Should I have a general receiver that caches events, so I can ask it for the missed ones? Or should I re-subscribe? Or just log a warning so I try to handle events faster?

Yeah, I would say mainly the last one, to identity that the current way of handling notifications is too slow, so fix it somehow, or increase the notifications channel capacity.