Add feedback form

[nesnoj]

This new feedback form will allow users to give feedback about an app.

After submission, a mail will be send (using a dedicated WAM Exchange account) to the address which is specified in the app's app.cfg by param email (example). The credentials for the Exchange account are taken from env vars (obtained in settings.py).
@henhuy Is there a more secure way to obtain them?

See helpers.rst for details.

Message format:

Sie haben eine Nachricht über das Feedback-Formular der WAM erhalten.

App: stemp_abw
Absender: Peter Meyer (peter.meyer@gmx.de)
Betreff: Testbetreff
========================================
Hallo,

dies ist eine Testnachricht.

MfG
========================================
Bitte antworte nicht auf diese E-Mail, junger PadaWAM!
Gez. Obi WAM Kenobi

Additional features:

• shows thank you page
• checks for required env vars, shows error page if not available
• on error during sending process, show error page

The send_email() function could be used for more notification stuff like status, errors etc.

[nesnoj]

Ok, fixed some Travis CI stuff but there're 2 errors left:

1. exception import errors -> do not make sense to me :(
2. exception too broad -> yes, but as fallback if error is unknown to log which one it is (cf. SO thread)

@Bachibouzouk any ideas how to handle this?

[Bachibouzouk]

Ok, fixed some Travis CI stuff but there're 2 errors left:

1. exception import errors -> do not make sense to me :(

@Bachibouzouk any ideas how to handle this?

Add # pylint: disable=import-error (on the line(s)) for which you want to disable this import-error (I read https://github.com/ecederstrand/exchangelib/issues/543 that it could be caused by a module overwriting a builtin module, but I tried rename the module and the function and still got the error...)

[Bachibouzouk]

2\. exception too broad -> yes, but as fallback if error is unknown to log which one it is (cf. [SO thread](https://stackoverflow.com/questions/30442236/how-to-prevent-too-broad-exception-in-this-case))

@Bachibouzouk any ideas how to handle this?

I think we can also add a # pylint: disable=broad-except on those lines. I think in general it is still good to try avoid the too broad except statements, this is why I didn't disable this warning flag.

[nesnoj]

Thank you @Bachibouzouk! I agree that it should remain enabled by default but it's also kind of absurd to keep it as long as there's no solution beside mockin' it out..
I didn't find a proper solution either so I'll just "fix" it as recommended.

[nesnoj]

The only missing thing is disabling the button after submit to prevent multiple submits. This can be solved after the JS error #71 is fixed.

[henhuy]

Wow! Very nice! Tried it and it worked nicely!
Only question I got: Why do you want to merge into dev instead of master?
regards

[henhuy]

and one more question:
should we put WAM_EXCHANGE_* into config file instead of env as we did with the rest?

[nesnoj]

Thanks for reviewing!

Only question I got: Why do you want to merge into dev instead of master?
regards

Because we decided to follow the Driessen git branching model (cf. CONTRIBUTING.md). So all new features are merged into dev which is subsequently merged to master for releases.

should we put WAM_EXCHANGE_* into config file instead of env as we did with the rest?

Good point, I'll change this.