[v2] Add session id to user agent string

[hssyoo]

This PR generates and appends a session id to the user agent string.

Description

A session id is an identifier that represents an AWS CLI usage session (ie a specific task or logical grouping of tasks). It has the following properties:

• Hashed using the host's name, TTY path (if available), and timestamp
• A session id is reused from the cache if it has been less than 30 minutes since the id was last used

Session ids are cached in a SQLite database stored in ~/.aws/cli/cache/session.db. An entry in the database consists of:

• key: Primary key that represents a cache key, which is a hash of the hostname + TTY path
• session_id: The session id associated with a hostname + TTY path
• timestamp: Most recent timestamp of the session id's usage

A cached session id is considered to be expired if it has been at least 30 minutes since the associated timestamp. On every AWS CLI invocation, the cache is cleared by deleting all entries with timestamps < current timestamp - (60*30) seconds. The cleanup job is processed in a daemon thread that terminates as soon as the main CLI process terminates to prevent blocking on cleanup tasks.

When determining the session id, it first checks the cache.

• If cache hit, check if the timestamp is expired
  • If not expired, update only the timestamp and write it back to table
  • If expired, generate and update session id and timestamp and write it back to table
• If cache miss, generate a new session id and write it to table

The session id is appended to the user agent string under the sid prefix. eg:

sid/090bcefb7f7cd3a77d9db442e378c0e1

Caveats

• Separating sessions between 30 minutes of inactivity is arbitrary and requires client code updates if we decide to adjust it. Future improvements could involve a smarter way to determine unique sessions, outside of relying on timestamps.
• TTY path is used to generate a session id because we want different screens to represent different sessions. There's not a reliable way to get something similar on Windows machines, so it'll only ever have 1 active session id at a time.

Why SQLite over files?

Caching session data in files can lead to race conditions when multiple processes are writing/reading to/from the same files. We can work around this by either implementing cross-file locks or writing to temporary files and moving them, but both approaches add complexity to implementation.

SQLite offers atomic primitives off the shelf, along with a few useful features:

• Write-ahead logging for improved concurrency
• INSERT OR REPLACE INTO for simpler writes
• DELETE .. WHERE for bulk deletes