The firewall service

Hello,

This request depends on exec() cleanup branch (mostly for convenience). Please merge that before this one for simplicity.

This branch attempts to introduce a firewall service in Plinth. It has two proposals:

1) Establish a framework for notifications and
2) Create a working firewall service

1. First is required for firewall (and other things) to be implemented cleanly. This is in reference to the discussion you have raised on the mailing list with subject "Cross Cutting Concerns in Plinth". I propose using Django's inbuilt signaling mechanism: Django Dispatch. 

2. Firewall service uses a service framework. I introduced service framework to have basic information about services being managed by Plinth available easily. Firewall service automatically enables and disables ports based on which services are enabled/disabled. I propose using FirewallD as a high level firewall management tool. Two other changes are complementary to this patch: we need to add a freedombox-setup command to enable web port and add firewalld in the freedom-maker package list (will submit patches soon).

**Django Dispatch Rationale**
- It is simple to use.
- All the responses of the callbacks will be available to notifier.
- It has filtering based on senders.
- It can be used independently of the rest of Django. It is not tied to Django. It is similar to using an separate library.
- It is readily available in Debian.
- It can be swapped out with another such framework (if chosen) with very little effort.
- Most importantly, Django seems to be an eco-system which could rely on more. See more on that in Django rationale.
- Minor: It will be efficient as it does not lookup from a global list or does not do pattern matching. This also has some disadvantages as I described in my mail.
- Minor: Django signaling seems to be widely used and inspired a lot of similar frameworks. Many other such frameworks simply provide similar functionality.
- Most of the other desired features of a notification system can be worked around with little difficulty.

**FirewallD Rationale**
- It works at a much higher level than iptables making configuration less error prone and easy.
- It has the concept of services which are installable XML descriptions of ports and protocols. We simply have to enable service "dns" instead of worrying about ports and protocols.
- Compared to other such tools, it is a daemon which is meant to be communicated with by other processes such a Plinth.
- Since it is a daemon, there is no restarting required after each configuration change. It simply inserts/deletes the rules appropriate for the operation just performed.
- It is possible to directly communicate with the daemon using DBus IPC instead of several levels of error prone command line tools.
- Custom iptables rules are possible.
- It handles permanent and currently running configuration separately giving nice features such as temporary "panic" mode to block all traffic.
- Swapping out FirewallD with another tool later is as easy as changing commands in the actions/firewall (mostly). After stable release FreedomBox though, we need a migration.
- It is readily available in Debian.
- It installs with very sane defaults blocking all services but SSH. We can enable http(s) ports from freedombox-setup.

**Django Rationale**
- Loose coupling philosophy. Django's components can picked in ala carte fashion. We can keep everything we have currently and pick whatever we need from Django such a form generation and validation API, dispatch API, messaging API etc.
- More than many other Python web frameworks, Django follows the explicit over implicit philosophy which helps in using it piece-wise and in easily understanding it. Shortcuts are clear and optional.
- Django covers more areas of web application development than other frameworks which claim "simplicity" and "small" size. For example, very few frameworks provide API for all of the following: forms handling, notification, testing, authentication, caching, messaging, mailing, i18n and logging.
- Django has a large eco system of contrib packages that we could possible pick in future for convenience.
- Django and many other related packages are readily available in Debian.
- Django is avilable for Python 3.