Architecture Discussion For v6

I was trying to integrate refresh tokens when I came across some issues.
The Architecture changes I'm going to propose should probably be for the next version v6 and not for now. I'm a bit confused on why the coinbase is inheriting from the FlurlClient.
This is creating a hard dependency on the FlurlClient. The client is subject to be changed (e.g) the last version was using RestSharp Client Perhaps their should be a protected property instead for the client, to abstract the depedency.

The current architecture makes it difficult to modify the request control flow, if someone wanted to catch an error such as expired_token, currently they would have to wrap every request made.

If the endpoints were made properties, and all inherited from the same base interface/ class, a builder could be used to construct the request, and the base class could have an execute function (similar to the prior version) which could be overridden to make it easier to change the control of each request.

For now I'm going to integrate the beta with my api.
lets discuss this more when you get a chance

No files, tests, or concrete entry points are named. Read the current Coinbase/FlurlClient inheritance and request-control flow first, then compare the proposed protected client abstraction, endpoint base type, and overridable execution path against the v6 scope. Done would require an agreed architecture and explicit scope.

Written by the indexing model from the issue text.