w3up client rewrite

[hannahhoward]

User Value

User feedback suggests our client has following issues:

1. Having multiple clients is confusing and can introduce issues with dependency management.
2. Client API is not clear about which spaces are under which accounts and which accounts client has sessions with.
3. Stateful client is not a great fit for the stateless environments like lambdas or CI workflows.

In addition to user feedback we also observed that

1. Iterating on features across multiple clients introduces significant overhead.
2. We have lots of historical code based on decisions that are no longer relevant and that complicates code maintenance.

Hypothesis

By rewriting our clients into a single client with a coherent interface we will improve user experience and reduce overhead of new development.

Subtasks:

• Review Irakli's rollout plan #26

See also:

• Future API Sketch w3up#1156
• feat: unified client w3up#1306

[reidlw]

Per Irakli: Hope this week, worst case next week

[gobengo]

@Gozala IMO It's hard to test whether anyone really likes a rewrite or not if we frame it as a major version upgrade that has happened whether they like it or not. What if we release this as a new package like w3s-client instead of backwards-incompatible rewrite of w3up-client? Then we could run an experiment to validate this hypothesis in a way that doesn't require a major version bump of w3up-client, but also doesn't prevent one later (one sprint or so) either.

[reidlw]

@Gozala @gobengo -> just reading Ben's comment above, I actually am thinking a short explanation of release plan for this would make sense in the description of the issue (or child issue?) Probably worth being explicit and give us a chance to identify needs like docs, website updates, comms, etc. Even if we wanted to do a test with some limited subset of users first?

[reidlw]

@Gozala need to add a 'Reviewer DRI'?