Allow passing initial seq, session_id and resume_url attributes to the shard, as well as retrieving them.

[davfsa]

• Additionally export all impl classes to hikari namespace

[FasterSpeeding]

guaranteeing these properties (esp seq) for all shard impls would conflict with shard impls which aren't running the shard logic in the current process

[davfsa]

We are not going to make a "extremely generic" API, because then we might as well have an empty class, because each implementation could do whatever they want and decide how it works.

The idea for our API is to expose what external interface we expect our components to have.

If someone wants to make their own interface and implementation of what we do, they can always define and implement their own.

Once we hit a stable release, this API would not change until a major version is released.

[FasterSpeeding]

We are not going to make a "extremely generic" API

It isn't "extremely generic" right now either? These are just niche properties which most ppl don't need and I'm just trying to weigh the pros vs cons of enforcing them for every implementation (when the only one which needs to be a property here (.seq) just straight out cannot always be implemented properly) as opposed to just keeping them implementation detail which would also work for the intended use case.

If someone wants to make their own interface and implementation of what we do, they can always define and implement their own

Also how would they "make their own interface of what we do" for Shard, that just wouldn't be compatible with with Hikari's ecosystem all just because of a Shard's sequence number?

The idea for our API is to expose what external interface we expect our components to have.

what's the point of the ABCs then, sounds redundant.