Fix: ensure valid environments for share request and other objects creation

[dlpzx]

Feature or Bugfix

• Feature
• Bugfix

Detail

The different alternatives considered are discussed in #556

This PR introduces a new query listValidEnvironments that replaces the query listEnvironments for certain operations.
listEnvironments - lists all environments independently of their CloudFormation stack statys with a lot of additional details
listValidEnvironments - lists only "CloudFormation" stable and successful environments. Retrieves only basic info about the environment.

Operations such as opening a share request or creation a Dataset/Notebook/etc require the selection of an environment. The environment options are now retrieved from listValidEnvironments ensuring that only valid environments are selectable. Moreover, this query is more light and does not need to query and obtain as many fields as the original listEnvironments, improving the efficiency of the code.

Relates

• Request for share is being sent for invalid environment (CREATE_FAILED) #556

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[dlpzx]

Testing

Local testing:

• ListEnvironments in environment view --> all environments appear
• listEnvironment options in dataset create, import, notebook create, ML Studio create, pipeline create, pipeline edit, worksheetview, dashboard import --> valid environments appear, invalid environments don't
• successful creation of dataset

AWS testing:

• CICD pipeline suceeds
• ListEnvironments in environment view --> all environments appear
• listEnvironment options in dataset create, import, notebook create, ML Studio create, pipeline create, pipeline edit, worksheetview, dashboard import --> valid environments appear, invalid environments don't
• successful creation of dataset

[noah-paige]

Minor Comment - could we change this import and for listEnvironment to be import { gql } from 'apollo-boost'; (similar to how we do for all other queries/mutations)

apollo-boost comes with graphql-tag package and want to keep imports consistent

[dlpzx]

Strangely listEnvironment query also imported gql from graphql-tag. I just changed both in my last commit. There are no more imports using graphql-tag

[noah-paige]

lgtm