[EPIC] Extend IOPointers to store values in addition to keys

[shreyashankar]

Context: the current IOPointer abstraction only stores a string "pointer" to the data, or a key. An example might be features.csv or model.joblib. This means we currently can't do anything with the data, because we don't store any concept of it. If we store data, we could do many things, including the following:

• Compare current values to historical ComponentRuns' values
• Identify whether files have been tampered with outside of ComponentRuns
• Have more fine-grained tracing (record-level)

Storing the data in its entirety may be expensive. For now we will store a hash of the data, to get us one step closer to being able to store the data. This itself may be complex.

Issues

• Create and run a DB migration to store values in addition to keys in the IOPointer. Change the PK to be (key, value) instead of just key. In the migration, old records should have null values. #215
• Modify store.get_io_pointer to return the IOPointer correctly. Modify IOPointer client-facing abstractions but treat the value as null. #216
• Extend the register decorator and log_component_run functions to log KV pairs for I/O. Rewrite set_dependencies_from_inputs to reflect the new IOPointer schema. #217
• Rewrite the trace functions to reflect the new IOPointer schema. #218
• Make a "forwards" tracing function in the store. #219
• Modify the UI and CLI to reflect all of the changes from the IOPointer rewrite. #220

In the future, we will incorporate an IOPointer "tag" model to store information about fine-grained tracing (i.e., PK values will be tags). This tagging is out of scope from the current project.

[shreyashankar]

Goal: Have all this done by September 15 EOD