Audit subsystem refactor

[lmsurpre]

We're doing a lot of transformations and I'm not convinced they're all needed.

The CADF events we generate have a lot of static content that will be the same for every event and the most useful information is stuffed into an attachment content field that is base64 encoded but with an odd byte marker at the beginning.

Also the current "audit" subsystem mixes a few concerns:

• provenance logging of who created/updated/deleted data on the system
• access logging for who accessed what data when

Is this still the right design for us? Does it make more sense to align the provenance side of this with the FHIR Provenance resource type?

Robin's suggestion: write just enough information into the database. Make any "formatting" of this info as some kind of read api vs emitting messages for everything...mostly for reliability purposes (transactional integrity).

[lmsurpre]

Today the integration point between the server and this audit component is the AuditLogService interface; especially its logEntry method which takes an AuditLogEvent object:

Note the missing javadoc on all these fields... it is not very clear what a field like "location" should be set to.