Execution log write functionality

[iamkelllly]

Context: https://github.com/ethyca/solon/pull/179#discussion_r738854293

We are looking to improve the way that execution logs write to the database. In the testing of the current implementation, we found that:

1. fields_affected in the logs incorrectly include data categories that were not specified on the erasure rule
2. There are execution logs for collections that have nothing erased on them at all. It seems like all nodes that are touched as part of the traversal have erasure logs created for them even if no data was specified to be erased there. And they have completed statuses/successful messages.
3. If you generate an erasure for an email that doesn't exist in the app, you likewise get all successful erasure logs

The purpose of the execution logs is to elucidate:

1. Explain what exactly was run
2. Whether anything failed in the execution run
3. (point to) why it failed

This differs from application logs, where the purpose is to be view holistic application activity (ie: authentication logs, retry logs, etc)

For implementing the next generation of execution logs, the open questions are:

• should we be overwriting same record for each log?
• • if not, does each log deserve its own row?
• • if so, how do we maintain history of logs for posterity?

[pattisdr]

@iamkelllly currently I don't think execution logs provide a lot of value because of the unaddressed issues specified above. These old bug still needs to be fixed https://ethyca.atlassian.net/browse/SOL-271. When the logs are being created, we're not using all the information available to us to paint an accurate picture about what fields are affected, the logs are too broad.

Additionally, the current state has each action getting its own row, we are not currently overriding the same record for each log. I find this really confusing to read, it's hard to tie together which logs are related to each other, and it generates so many logs. I'd rather see one log for each node that we're constantly updating, but if we want all the history, then a ticket to group related logs together in the display would be handy.