local deployment: token request page missing request date information

[tiborsimko]

(1) When connecting first time to REANA Web UI, the user can ask for a token:

After user asks for a token, we add a confirmation that the token was requested:

However this happens only on the CERN instance. For local deployments, the page does not change.

We should add this.

(2) While we are at this, elsewhere on REANA Web UI we used the following date and time formats:

Let's use YYYY-MM-DDZhh:mm:ss consistently also here instead of 11th Sep....

[audrium]

We've found out that the issue appears because "api/token" request returns 500 error since the SMTP envars are not set in the reana-server. So to fix this issue couple of more things needs to be improved:

• Add generic error notification component to inform users when something goes wrong (React Error Boundaries could be used)
• Improve redux actions to catch the errors

[tiborsimko]

In addition:

• There was no asked-for-request item in the DB tables as a result of email failure. I think we should treat the email notification as just that, that is a notification. So, if the token request can be well processed on the backend side (because the DB is up and running nicely), then let's process it and let's treat the email notification as another secondary failure (becase the email server is down or something). In this way, the core functionality won't be disturbed by the notification functionality. This is because admins could be alerted by several means, e.g. via email notification, e.g. via a web page where these token requests will be listed, etc. So let's consider the email notification as not mandatory, and let's treat it as a "continuable error", not as a "fatal error", on the backend side.

• There was no entry in audit_log table about this failure. We may want to also log failed requests somewhere, since token business is kind of critical. What about logging also failed attempts in the same table with another status? We may want to look into improving error logging, so that cases like these would be available for easier peruse. (Something for later; in this issue we can improve (i) front-end error reporting so that users see what's happening and could ask for help; (ii) back-end handling so that if an email server is down, it wouldn't prevent the token request from being asked for.)

[audrium]

Closed with #120