[...After v2.4] Refactoring getStack API

[noah-paige]

Feature or Bugfix

• Feature
• Bugfix
• Refactoring

Detail

• Add additional permission checks to ensure read permissions on specific target resource in order to call getStack

• Removed StackStatus component from frontend because....

  • (1) StackStatus was also calling getStack but without target_uri or target_label (rather than update to include new inputs it did not seem necessary, continued explanation below)

  • (2) it appears StackStatus primarily defined in order to setInterval() to keep checking on stack status on a recurring basis

    • But this interval clears when the component unmounts and user switches to a new UI view in data.all

    • Found in practice that this is not always reliable at least with current implementation of getStack() being run on an interval of every 10 seconds

    • We already call getStack and save the latest status when we resolve the stack field for the object we are viewing (i.e. resolve_stack child resolver in DataPipeline Object Type)

    • The rationale for using interval I imagine is to make sure we have latest stack status reflective of actual state of data.all resource (which can be used in some cases such as listValidEnvironment())

      • I think would suffice if stack status already get resolved and updated when viewing object once (which it does) and then refreshing Stack Page of object can update further

Additional Thoughts:

• (OPTIONAL) Add back the StackStatus component primarily for the snackbar notifications based on status value

• (OPTIONAL) Add a background recurring ECS task that describes all stacks and updates status according (to ensure we continue to have a more accurate reflection of stack status)

Relates

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.

[SofiaSazonova]

About first point

Add additional permission checks to ensure read permissions on specific target resource in order to call getStack

Do we need it? Is there any way for user to getStack without entering the resource page first?
Security is cool, but may be it's overkill.

[noah-paige]

Moving this PR to v2.6 so we can take time to discuss and align on this

[dlpzx]

As a third option I would rescue the EventBridge notifications from environment to central account design by @SofiaSazonova in #922