Rework the callback mechanism to use event posting instead of simpler model update notifications

[Crsi]

First, remove the current callback mechanism (not the endpoints, for now).

Then, add a single callback POST /event instead of the current mechanism using three different GET requests of the form /{action}/{model}/{id}.

Events should be buffered for a configurable duration (up to a few seconds).

The JSON payload sent to the /event callback URL is a list of Event objects of the following form:

{
    "number": 3,
    "events": [
        {
            "event": "NAME_OF_THE_EVENT",
            "timestamp": UNIX_TIMESTAMP,
            "data": {
                // Any further data supplied with the event callback
            }
        },
        {
            ...
        }
    ]
}

Currently, the following event types with their custom additional data are suggested:

• server_started
  • base_url refers to an optional commonly known base URL where the API is usually reachable (excluding API versions and trailing /; may be null if unspecified or unknown)
• alias_confirmation_requested
  • id refers to the unconfirmed alias
  • user refers to the user ID ('owner' of the alias)
  • app refers to the application name of the alias
• alias_confirmed
  • id refers to the confirmed alias
  • user refers to the user ID ('owner' of the alias)
  • app refers to the application name of the alias
• communism_created
  • id refers to the created communism
  • user refers to the user ID of the creating user
  • amount refers to the total amount to be shared in the communism
  • participants is the number of participants in the communism (static 1 for this event)
• communism_updated
  • id refers to the updated communism
  • participants is the new number of participants in the communism (accumulating multiple quantities)
• communism_closed (this event will also be fired for successful abort operations)
  • id refers to the closed communism
  • transactions refers to the number of transactions originating from closing this communism
  • aborted determines if the communism was aborted (false for normal closing)
  • participants is the final number of participants in the communism (accumulating multiple quantities)
• poll_created
  • id refers to the created poll
  • user refers to the user ID which has requested to become an internal user
• poll_updated
  • id refers to the updated poll
  • last_vote refers to the optional ID of the last vote (null if the update wasn't triggered by a new vote)
• poll_closed (this event will also be fired for successful abort operations)
  • id refers to the closed poll
  • accepted determines if the poll was accepted or not
  • aborted determines if the poll was aborted (false for normal closing)
  • user refers to the user ID which has requested to become an internal user (ignoring whether the request has been accepted or not, see accepted for that)
  • last_vote refers to the optional ID of the last vote (null for aborted polls)
• refund_created
  • id refers to the created refund
  • user refers to the user ID of the creating user
  • amount refers to the total amount the creating user wants from the community
• refund_updated
  • id refers to the updated refund
  • last_vote refers to the optional ID of the last vote (null for aborted refunds)
  • current_result refers to the current balance (positive means users approved the request, negative means users disapproved the request) of the refund
• refund_closed (this event will also be fired for successful abort operations)
  • id refers to the closed refund
  • accepted determines if the refund was accepted or not
  • aborted determines if the refund was aborted (false for normal closing)
  • transaction refers to the transaction ID associated with the refund (null for failed & aborted refunds)
• transaction_created
  • id refers to the created transaction
  • sender refers to the user ID of the sender
  • receiver refers to the user ID of the receiver
  • amount refers to the amount of the transaction
• voucher_updated
  • id refers to the user which has been updated, i.e. the debtor user
  • voucher refers to the optional ID of the vouching user
  • transaction refers to the optional transaction ID when a voucher stopped vouching for a debtor
• user_softly_deleted
  • id refers to the user that has been softly deleted

[Crsi]

This has been implemented, tested and merged into dev.
Maybe some more details are added to those callbacks in the future, but for now this is just enough.