Add Date.now() to expiry when passing it to Expiration

[Neon-White]

Explain the changes

1. The Expiration field in the response to AssumeRole returned the value in milliseconds; it should be in seconds, and added to the current time; this is now fixed
2. generate_session_token() passed expiry in milliseconds when make_auth_token expects seconds, this is now fixed
3. It is now possible to provide an expiration in seconds by providing the AWS CLI flag --duration-seconds

Issues: Fixed #xxx / Gap #xxx

1. Fixes BZ#2299801

Testing Instructions:

1. Follow the STS test section here, observe the return value of Expiration:
2. Try to utilize the credentials and observe whether they expire in the timestamp shown in the previous step

• Doc added/updated
• Tests updated

[shirady]

LGTM

[guymguym]

final minor comments

[guymguym]

The code looks ok to me, but did you test it with aws sdk?

[Neon-White]

@guymguym - Thanks for the reviews and input, I will make sure to verify it with AWS CLI and fix the unittest prior to merging

[Neon-White]

@guymguym - The PR seems to work great with the AWS CLI, a few points I noticed:

1. Permissions are enforced as expected
2. The printed expiration timestamp is in GMT+0 regardless of the system time
3. Sadly, the range validation errors don't seem to function as intended, since the CLI returns An error occurred (Unknown) when calling the AssumeRole operation: Unknown, even though the logs very clearly show that the correct exception was thrown -

[Endpoint/13] [ERROR] core.endpoint.sts.sts_rest:: STS ERROR <?xml version="1.0" encoding="UTF-8"?><Error><Code>ValidationError</Code><Message>Value 400000 for durationSeconds failed to satisfy constraint: Member must have value less than or equal to 43200</Message>

Any chance you already know why that'd happen?
If not, I suggest merging the PR in its current state and taking care of this problem in a separate PR (or creating an issue to track it)