Reuse field names across different event types in EventSinkService

[bodom0015]

Description

Problem

EventSinkService is missing some last bits of wiring to get it working end-to-end with InfluxDB.

Approach

• Make fields a bit more consistent/generic (to encourage reuse across events)
• Include the category and a created timestamp with the message

How to Test

Prerequisite: Clowder running locally, configured to talk to RabbitMQ, RabbitMQ running

NOTE: This will work with InfluxDB 1.8.3, but will need modifications to work with their new 2.0 release

1. Start up an InfluxDB instance:

docker run -itd --name=influxdb -p 8086:8086 -v $PWD/influxdb:/var/lib/influxdb influxdb:1.8.3

2. Checkout and run InfluxDB consumer locally: git clone https://github.com/clowder-framework/event-sink-consumers -b sync-fields && cd event-sink-consumers/influxdb/ && ./build.sh && ./recv.sh
   • See other PR for related changes to the InfluxDB consumer
3. Checkout and run this branch locally in Clowder
4. Log into Clowder
   • You should see a message appear in the Clowder logs that a User has logged in
   • You should see the same message sent through RabbitMQ to the Influx consumer logs
5. Verify that the event now appears in InfluxDB (note the single-quotes around the value in the WHERE clause):

> SELECT type,user_name FROM events WHERE category="user_activity";   <-- NOTE: this returns nothing - single-quotes needed
> SELECT time,user_id FROM events WHERE category='user_activity';   <-- NOTE: this returns nothing since we're only querying "tag" columns
> SELECT type,user_name FROM events WHERE category='user_activity';
name: events
time          type  user_name
----          ----  ---------
1615321785536 login Mike Lambert

6. Test out other events and verify that they work similarly:
   • User Logins / Signups
   • Upload Files
   • View Spaces/Collections/Datasets/Files
   • Download Datasets/Files
   • Submit Extractions

Review Time Estimate

• Immediately
• Within one week
• When possible

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the CHANGELOG.md.
• I have signed the CLA
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.