feat: new statement store API

[Nemanya8]

No description provided.

[josepot]

Thanks for putting this together. I’ve skimmed the PR and I think there are a few significant issues to resolve before it’s ready, primarily around how subscriptions are handled. There are also some secondary issues (including type-level decisions that could result in an inconsistent or less ergonomic API).

One important note on timing: we’ve been operating unfunded for the last two months, so we can’t commit to an urgent review or quickly reacting to upstream changes that weren’t coordinate with us.

We’ll try to take a deeper look next week, but our current focus is on securing sustainable maintenance for the core libraries of PAPI. Because this SDK doesn’t directly or indirectly generate revenue, unpaid work on it is unfortunately at the bottom of our priorities right now.

We also shared a recent maintenance/status update here for expectations.

[voliva]

Thanks for the PR, however this one has many issues that led me to solve it in a different PR: #64

• The subscribe parameter that this implementation requires is not compatible with PAPI client's _subscribe method - It's a different interface.
• At this level of abstraction, the primitive for subscriptions are Observables. Makes them easier to compose, transform and manage their lifetime.
• I'm not sure exposing expiry directly is valuable. If the way of interacting with Statements is with timestamp + sequence number, I think it's better to have it decode to those two fields, rather than leaking that parameter and then having to extend the API surface with more methods or utilities to help deal with that.
• I'd rather keep a smaller API surface for filters. I think it's fine offering some defaults (broadcasts + posted), but sounds like that could be one same API/request that can get filtered differently afterwards.

Please @Nemanya8 take a look at #64 and let me know if I overlooked something. I'm happy to have a call if you think it's needed.

My biggest questions / assumptions I took:

• What to do on malformed statements? This implementation swallows the error, feat(statement-sdk): subscription based statement store #64 would throw and terminate - IMO failing fast is valuable, but I'm not sure if there are use cases I'm missing.

CC @valentunn