Set up a handling mechanism to catch error messages when accessing Kibella's internal database or cache

[mastropi]

This issue is related to a high-priority request by Frank that the backend sends an error message to the interface that any one of the internal databases/directories used by Kibella is not accessible (most likely because of limited permissions).

Quoting Frank's message on 14-Jul-2020:

Under linux, by default, the directory "kibella/tempdata/cache" has the following limited permissions:
drwxr-xr--
For kibella to work the permissions should be set to:
drwxrwxrwx
The fix is: You can easily change the permissions using a command such as:
sudo chmod 777 tempdata/cache/
...but before fixing this error, you must know that it exists! ..and currently, the interface does not receive any error message when this error happens: i.e. it just simply "spins", waiting for a response (that never arrives).

I clarify here that the backend does send an error message to the interface already, but not in a format that can be handled by the interface (e.g. JSON).

--
NEXT STEP:
We need to coordinate the communication mechanism between the backend and the interface so that the latter can show a proper message to the end user.

[mastropi]

As agreed with Matthieu after our call this morning, to begin with we will implement a response from the backend with the following format:

{
	"message": {
		"type": "error",
		"value": "Error message here"
		}
}

On the frontend, the message will be displayed as a red banner via a notifier.

The error message related to this issue can be triggered at any of the following contexts in the Kibella client:
(the third column shows the pattern matching performed by the backend (requests.php) on the URI received with the request; the fourth column is for my reference)

[Kranf99]

This looks great! This is ok for me!

[mastropi]

TODO: (2020/08/22) Once the interface is able to handle the above JSON string with an error message to display, the backend should be adapted so that all error messages are sent using that JSON protocol; and probably additional error/warning messages should also be sent in order to provide the user with suitable information.

For the adaptation of existing error messages, look for all calls to showMessage() and calls to echo of exception messages. For example, there are many of these in classes.php that are related to the the connection to databases.

For new error messages, there are already some commented out in dbDBHExecuteSqlQuery() when the query to execute is ill-formed. Note that this can be caused by the user typing an incorrect filter expression in the free-text box that can be used to filter data.

[Kranf99]

The frontend code now contains a little piece of code that cannot be transpiled using the standard "grunt dist" command because grunt does not support yet the new extended javascript syntax (using arrow-expression "=>"). More precisely, inside the file "interface/elasticsearch.angular.js", there is one usage of "=>" that prevents all "grunt dist" commands to work. This little piece of code needs to be converted back to "standard" javascript.

Currently, to still be able to transpile the code, I follow these steps:

1. Inside the original source code, I replace this line:
   }).then((response) => {
   with
   }).then( function (response) {
2. I transpile the code
3. Inside the transpiled code, I replace this :
   }).then( function (response) {
   with
   }).then( (response) => {

This is ugly.
Needs fixing...

[Kranf99]

Also: no banner is displayed when the message is sent from the formRegisterTableSubmit.php script.