Job Status Update: Implement RabbitMQ Action

[despadam]

Description

Fixes #1121

Motivation

The RabbitMQ action is a requirement for PSI

Fixes:

The changes made in JobOperation class in jobconfig.ts and in job-create.interceptor.ts fix the way we are storing the configuration in each job created in the database. Previously, the part of configuration file for actions was replaced by the action instance information, which in some cases makes the result we see in the database incomprehensible. We now store the action information exactly as it comes from the json file. This fix provides readability and reproducibility.

Changes:

• jobConfig.example.json: added configuration for the rabbitMQ action
• jobs.controller: added function to call the relevant actions on job update
• rabbitmqaction.ts: makes a RabbitMQ connection, creates a channel and sends a message in the queue

Important: In order to spin up RabbitMQ, one needs to update the .env and docker-compose.yaml files in scicat-ci. These changes have been made in despadam/scicat-ci:dev-docs fork and should be merged as well.

Tests:

To test whether the message has been published, one can login to the RabbitMQ management page on localhost:15672 with the default credentials and inspect the queue.

Notes:

The discussion about whether we should store the full configuration in each job should remain open. Storing configuration per job means that each job can run with different configuration. However, even if this has been implemented in the job schema (see also the fix mentioned above), we tend to not utilize it. More specifically, authorization in casl-factory and action initialization are still using the SciCat running instance configuration, instead of the job specific one, which is contradictory.