Fixes

[reginafcompton]

Overview

This PR handles the following Clubhouse cards:

• https://app.clubhouse.io/brighthive/story/470/more-robust-error-handling-logging-in-get-access-token
• https://app.clubhouse.io/brighthive/story/469/re-use-auth-access-token-across-executions-of-health-audit-runner-py
• https://app.clubhouse.io/brighthive/story/471/close-engine-connections

Getting and using tokens

With this PR, the process for getting a token and hitting a secure endpoint unfolds like so:

1. Request a token
2. Store the token in a tmp file
3. If the token cannot be requested, then store an "invalid token" in the tmp file
4. Read the token from the tmp file, and use it to GET the MCI and DR APIs

Handling database connections

This PR also insures that the metrics collector properly closes database connections. This includes two major changes:

1. Instantiate the database engine ONCE, i.e., at the beginning of the audit function. This differs from the original solution, which instantiate an engine every time the script executed.

The typical usage of create_engine() is once per particular database URL, held globally for the lifetime of a single application process....the Engine is most efficient when created just once at the module level of an application, not per-object or per-function call. (SQLAlchemy Docs)

2. Explicitly open a data base connection and close it after running a query:
   

   data-trust-logger/data_trust_logger/health_audit/metrics_collector.py

   Lines 28 to 31 in ca5b3d5

   	connection = engine.connect()
   	result = connection.execute(f"SELECT COUNT(*) from {endpoint}")
   	count, = result.fetchone()
   	connection.close()

[gregmundy]

The solution seems reasonable, although I would think you'd want to save yourself some overhead and simply maintain the token in memory since the application doesn't actually exit. Even if the container died or restarted, the temp file wouldn't persist and you'd have to retrieve a new token anyway.

The concern I have here is that by writing it to a temp file is that you're exposing the token outside of the application (meaning I could log in to a node and see the contents of that file). But, if someone from the outside were logged in to our k8s cluster, we'd have much problems. This becomes more dangerous if you're running the logger API outside of k8s (which is possible). No need to fix right now, but may need to re-think that solution in the future.