sdk: add FilterOptions

[yukibtc]

Closes #119

[ok300]

LGTM. I tested both of the new variants and they work.

I found one weird edge-case, where using FilterOptions::WaitForEventsAfterEOSE(x) actually waits until timeout, even if x events were received after EOSE. This happens when one of the relays is unresponsive and runs into timeout. In a sense, it behaves as expected, so I'd just ignore this for now.

[ok300]

I experimented with a different approach: #129 . I tested all 3 branches and they work.

I mainly tried to make the inner logic more readable and easier to reason about.

What do you think?

[ok300]

On second thought, your new version is actually simpler. I closed my PR.

[ok300]

I found a bug in your version:

timeout doesn't just mean "timeout to EOSE", it means "timeout until function returns".

So calling it with

• timeout of Duration::from_secs(1) and
• FilterOptions::WaitDurationAfterEOSE(Duration::from_secs(5))

will return after 1 second with a timeout (even though EOSE came on time).

[yukibtc]

Yes, the timeout should be intended as "timeout until function returns".
The WaitDurationAfterEOSE should be executed outside the timeout?

[ok300]

IMO the simpler approach is better:

• timeout refers to "timeout until EOSE" (could be renamed to better indicate that)
• WaitDurationAfterEOSE is completely separate and up to the caller

I see two big reasons for this:

1. It's backward compatible, so people who used timeout in the "timeout to EOSE" sense so far, will not be confused or surprised by a change in the meaning.
2. After EOSE, there's no way to tell when a query "times out" (resulting in Err), or when the WaitDurationAfterEOSE was waited as per the filter option (success case, resulting in Ok).

[ok300]

Tested all 3 versions, with different timeout combinations, all work 👍