[GSK-2782] Allow GiskardClient to read api key from env

[vjern]

Description

There exists an env var called GSK_API_KEY used to auto-provide the API key in the giskard worker CLI. It makes sense to reuse the name here.

We may want to also delete it from the environment once it's loaded to prevent leaks as done in the CLI.

I'm worried though that it may destroy the env var in the kernel itself, which would need to be restarted to properly instantiate a new client (or if the user was to reload the same cell where the client gets created).

Todo

• Update client instantiation documentation to include (or update) a section on setting environment variables so they get picked up by GiskardClient.

Testing Checklist

• Spin up a notebook with previously set env vars among which GSK_API_KEY
• Spin up a client without key kwarg and connect to the hub
• Destroy env var (del os.environ['GSK_API_KEY']) and attempt to re-instantiate client
  • This operation should ideally be idempotent. We could store the env var value as a class field or another property that will not get uploaded with the test code.

Related Issue

Type of Change

• 📚 Examples / docs / tutorials / dependencies update
• 🔧 Bug fix (non-breaking change which fixes an issue)
• 🥂 Improvement (non-breaking change which improves an existing feature)
• 🚀 New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to change)
• 🔐 Security fix

Checklist

• I've read the CODE_OF_CONDUCT.md document.
• I've read the CONTRIBUTING.md guide.
• I've updated the code style using make codestyle.
• I've written tests for all new methods and classes that I created.
• I've written the docstring in Google format for all the methods and classes that I used.

[linear]

GSK-2782 Hide Giskard API key from the Notebook

[Hartorn]

Nitpicking here, but could you put this check earlier ? like line 133

It's good practice to validate as soon as you can, then do the logic