Merge Changes from Dev into Master

[epierce]

• Fixed reading the force_classic parameter from the config file
• Changed the default behavior for a missing value on force_classic
• Disabled the DT cookie when in force_classic mode
• Changed the source file filename to fix HomeBrew deployment

Description

The default behavior is to treat any missing or empty parameter in ~/.okta_aws_login_config as False. This causes an issue for orgs that are migrating from Okta to Classic to OIE because it forces all users to use the --force-classic parameter, modify their config file directly or run gimme-aws-creds --configure after migration to update the force_classic value.
We want to make migrations as seamless as possible for users, the default behavior from now on will be to treat a missing or empty value for force_classic as True. This will make gimme-aws-creds behave in the same way before and after the migration. You can then create a new OIDC app for the device authorization flow and have both flows available for a phased transition to the browser-based login.

When using a Global Session Policy that triggers MFA based on the DT cookie and an application policy that requires MFA, OIE uses the "step-up authentication" process, which is not supported by gimme-aws-creds "classic" mode. Disabling the use of the DT cookie avoids this situation and makes the classic mode useable in more auth policy configurations.

The move to building gimme-aws-creds using PIP instead of setup.py starting in 2.8.0 changes the filenames that were output, which broke the homebrew build (homebrew doesn't recognize that gimme-aws-creds has updated). The updated filename configuration should take care of this issue.

Related Issue

#455
#454
#452

How Has This Been Tested?

Tested with migrating domain from Classic to OIE and updated unit tests

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• [] I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.