views: define signals for view methods

[slint]

At the moment, there is no official way to perform any actions before or after a record REST API request (or to be more precise, after a record CRUD operation has been committed to the database).

Sending signals at the end of each REST resource method would be a solution to this problem, and allow for such pluggable actions. The end result would be something like after_records_post, after_record_put, after_record_delete, etc.

The ugly part

Although this might be frowned upon since it's introducing the danger of a user of the module modifying the database state or creating side effects, it's a logical use case for when there is a need for sequential execution of actions. A common example is record indexing, where a created/modified/deleted record should be sent for the appropriate indexing operation on ElasticSearch, in order to appear or be removed from the search results. This would prevent the following pattern from happening:

1. POST /api/records
   • DB transaction started
     • Payload validated
     • Record with PID recid:1 created in transaction
     • Record sent for indexing
   • DB commit fails
2. GET /api/records
   • Record with PID recid:1 available in results
3. GET /api/records/1
   • 404 Not found

(Another issue is the fact that signals have proven to be hard to debug, especially in complex operations (eg. deposit actions), so introducing more of them won't make things easier... This though is general issue that might need better handling on a global level, such as better documentation of signals or keeping a programmatically accessible registry of signals for debugging purposes)