Feat filter selection: adds --filter-selection/-f option to filter generated role selection screen

[acoppolawb]

Description

This option will filter out the list of roles generated when calling gimme-aws-creds to show only those that contain a match on the passed in string.

Example: gimme-aws-creds might return:

Account: myaccount-poc (#)
  [ 1 ]: Admin
Account: myaccount-dev1 (#)
  [ 2 ]: Admin
Account: myaccount-dev2 (#)
  [ 3 ]: Admin
Account: myaccount-prod (#)
  [ 4 ]: Admin
Selections (comma separated): 

And gimme-aws-creds -f dev would return:

Account: myaccount-dev1 (#)
  [ 1 ]: Admin
Account: myaccount-dev2 (#)
  [ 2 ]: Admin
Selections (comma separated): 

If only one match is found, it is auto selected (already the default behavior - not part of this feature).

If the user has their ~/.okta_aws_login_config file set so that aws_rolename = all then passing in the -f option causes creds to be generated against the filtered list instead of every role available to the user. I.e: gimme-aws-creds -f poc would grab creds only for matching roles, whereas aws-gimme-creds would still grab creds for all roles.

Related Issue

None

Motivation and Context

This change is helpful for users with access to many roles. For instance, my team at WarnerBros has access to hundreds of roles across hundreds of AWS accounts, and selecting the one we need at a given time from a long list is tedious. This option lets us call the specific account we need access to, or a part of it (the list of poc accounts, or dev accounts, or prod accounts), and select from a much smaller list.

How Has This Been Tested?

This change was tested manually by running:

1. gimme-aws-creds by itself and verifying the resulting list.
2. gimme-aws-creds -f poc and verifying the resulting list, selecting one and verifying the resulting creds worked with an aws --profile aws-aio-poc sts get-caller-identity call.
3. gimme-aws-creds -f aws-aio-poc and verifying the generated creds worked with an aws --profile aws-aio-poc sts get-caller-identity call.

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.