Consider a more object-oriented API

[mfisher87]

I've been thinking about the current architecture and statefulness of earthaccess, and the sustainability of those choices.
I'll admit I haven't thought deeply about this but I want to put it out there and see how it resonates or doesn't resonate.

TLDR

Based on our quickstart:

import earthaccess

ea_uat = earthaccess.client(system=earthaccess.UAT)
ea_uat.login(strategy="netrc")
results = ea_uat.search_data(
    short_name='ATL06',
    bounding_box=(-10, 20, 10, 50),
    temporal=("1999-02", "2019-03"),
    count=10,
)
ea_uat.download(results, "./local_folder")

Other methods on the client, e.g. client.system_status(), client.search_services() respect choices made at client initialization.

Or something.

Benefits

• Testability for us: Less statefulness to think about by eliminating the current global _auth interface.
• Testability for users: Can create fixtures that test their code with UAT or PROD and be more confident about state
• Users can "save" some of their choices in the client, e.g. which system it's using, and be more confident that they haven't "missed a spot" somewhere in the code.
• Ability to make some additional breaking changes at the same time, e.g. an enum for auth stategy? What else? The results class comes to mind but IIRC we intended to make that class iterable to avoid a breaking change.
• Exercising our policies for breaking changes
• Setting expectations for users when we make breaking changes
• Being our first major breaking change, establishing confidence that we can successfully navigate breaking changes as a community

Costs?

• Instead of "NASA data in 3 lines of code", "NASA data in 4 lines of code"
• Users deal with a breaking change to an interface they know and love
• Labor -- programming the feature, updating our tests, docs, outreach
• Other? Edit me!

These costs are not insignificant. That said, it's sometimes worth the cost for sustainability and maintainability. Is this one of those cases? 🤷

Cost mitigation

How much of those costs can be mitigated by changing the architecture and building convenience methods on top which maintain the current API (i.e. user does earthaccess.login() and we create a global singleton EarthaccessClient instance under the hood)? Is that a worthwhile compromise? What costs will the compromise itself incur? If we do the compromise, should it be temporary and come with DeprecationWarnings?

What am I missing?

Y'all know better than me, please tell me 😁