fixed all aws query runners auth

[AndrewChubatiuk]

What type of PR is this?

Currently Athena supports only a limited amount of auth methods depending on ASSUME_ROLE and OPTIONAL_CREDENTIALS flags values:

• ASSUME_ROLE: true, OPTIONAL_CREDENTIALS: true - athena client uses assume role credentials retrieved using sts boto client with aws default credentials provider chain
• ASSUME_ROLE: false, OPTIONAL_CREDENTIALS: true - use athena client with default credentials provider chain
• ASSUME_ROLE: true, OPTIONAL_CREDENTIALS: false - same as first option
• ASSUME_ROLE: false, OPTIONAL_CREDENTIALS: false - athena client uses static credentials

These scenarios do not cover cases when:

• there a need to use different scenarios for different athena datasources, e.g.: one uses static credentials, another one assumes role. ASSUME_ROLE and OPTIONAL_CREDENTIALS flags are global for a whole redash setup
• when static credentials should be passed to a sts client

In this PR propose do not use ASSUME_ROLE and OPTIONAL_CREDENTIALS flags at all and use the same approach for all aws query runners, which allows to cover all possible scenarios:

• aws_access_key_id and aws_secret_access_key are set and role_arn is not set - use static credentials for service client

• aws_access_key_id, aws_secret_access_key and role_arn are all set - use static credentials for sts client and use assume role credentials for service client

• only role_arn is set - use default credentials provider chain for sts client and assumed role credentials for service client

• none is set - use default credentials provider chain for service client

• Refactor

• Feature

• Bug Fix

• New Query Runner (Data Source)

• New Alert Destination

• Other

Description

How is this tested?

• Unit tests (pytest, jest)
• E2E Tests (Cypress)
• Manually
• N/A

Related Tickets & Documents

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

[AndrewChubatiuk]

@justinclift need your review here as well