DAS-1966 - Include documentation notebook for CMR GraphQL.

[owenlittlejohns]

Description

This PR adds a documentation notebook showing how to programmatically make queries to the CMR GraphQL API and retrieve UMM-Var records. This notebook is derived from William Valencia's recent Inspect and Adapt demonstration, but has a little bit more descriptive prose added to it.

Jira Issue ID

DAS-1966

Local Test Steps

• Follow the environment set-up information at the start of the notebook (create/activate a Python environment, and pip install notebook requests).
• Run through the notebook cells.
• The notebook will complete, but you'll see errors returned from CMR GraphQL (unless you are requesting against a local CMR GraphQL API using William's DAS-1900 work). These errors are expected, because the generateVariableDrafts is not available yet in SIT, UAT or production.

PR Acceptance Checklist

• Jira ticket acceptance criteria met.
• CHANGELOG.md updated to include high level summary of PR changes. (No changes to earthdata-varinfo code)
• VERSION updated if publishing a release. (No changes to earthdata-varinfo code)
• Tests added/updated and passing. (No changes to earthdata-varinfo code)
• Documentation updated (if needed).

[eni-awowale]

Looks good! I just had a few questions about Authorization stuff.

[eni-awowale]

I have couple questions with the authorization stuff (classic):

1. Can we use Launchpad tokens for this yet?
2. Would someone always have to create a txt file or could they enter the token like we do for all earthdata-varinfo functions?
3. Also do you think it would be worth putting the Authorization stuff in the beginning after the import cells?

[owenlittlejohns]

1. Yup. LaunchPad tokens are valid for auth, but they are a bit of a pain to set up. (I should probably include that link you have in your notebook for that)
2. Nope they wouldn't have to have the txt file - I left the code cells mostly unchanged (except for PEP8 stuff, of course), but my preferred way would be to retrieve an token from EDL via requests, but I thought that would clutter up the notebook and distract the user from the meat of the documentation, because it's probably another 20 lines or so of code. I could implement that instead, or I could add some text to describe a couple of alternative ways to get the token. (Do you have a preference?)
3. This is probably a personal preference, but prefer to have this right by the place where the token is being retrieved. Just because someone getting to this point of the notebook will have both the cell that does something with a token and the documentation about that token on the screen at the same time without scrolling. Sure, will do.

• Add link for LaunchPad token documentation.
• Clarify methods to get a token.
• Move auth higher up the notebook.

[owenlittlejohns]

Ha - I totally misunderstood 3... I clearly was thinking of the other notebook, because there's not the same level of auth documentation as you provide there. I can move this stuff higher up if you like, sure.

[owenlittlejohns]

As discussed in Slack, I added a helper function that retrieves an EDL token programmatically instead of using a text file. (I like this better, but hopefully the notebook is still fairly concise)

[eni-awowale]

Yes! I think it's a lot better and I will definitely be using that edl helper function!

[eni-awowale]

Thanks for adding more of the authorization information!