Pagekite using augeas

Created by: fonfon

To review this pull request, copy the augeas pagekite lens into your system:

cp data/usr/share/augeas/lenses/pagekite.aug /usr/share/augeas/lenses

Sorry for the additional pull request, I somehow messed up #96. Please review this pull request instead. My comments (just copied from #96):

Most of the pagekite actions are handled via augeas now. Users can:

• use any frontend server, not only pagekite.net
• use ssh
• define custom services: raw/http/https with any frontend to any backend port

This closes #46 (closed) except for "Explore using other FreedomBoxes as frontend servers", which is an interesting option and I don't see why it shouldn't work.

This pull request got bigger than I thought, I'm happy about proposals how to implement some parts in a simpler/cleaner way.

Further notes:

• the pagekite lens included here is not the one that's in the most recent pagekite release. The pull request is pending: https://github.com/hercules-team/augeas/pull/193. That's no problem because custom lenses have precedence over dist lenses, see https://github.com/hercules-team/augeas/blob/b61a78d2e629e4f1395270a1ee72876e27b12990/src/augeas.c#L497 -- so our lens will be used even if later on the old lens gets installed via the (not yet existing) debian package.
• In two cases the config can't be written using the pagekite lens (that's perhaps a bug or missing entries in the lens). In these cases the config files are changed via python.

Some thoughts about pagekite and its configuration that you don't have to read to review the pull request:

• it's strongly and unnecessarily bound to pagekite.net which is surprising for a debian package. pagekite --add 80 mybox.customdomain.net will just tell you to either use a pagekite.net account or configure your services manually.
• so you configure everything manually and get the services running. The pagekite --list command won't detect your services (i.e. HTTPS) although they are up and running. To remind you, that's the same program that actually runs the services.
• theoretically, the pagekite command would offer all options we need: configure frontends and list, add and disable services. But it's too unreliable/buggy to use programatically.
• the configuration is awkward. There are literals like abort_not_configured (which should mean run_as_service=no or so) and defaults (which will use the pagekite.net frontend and should be deleted entirely, just use frontend=pagekite.net ).
• because of these literals it's not valid .ini syntax (which is my smallest concern)
• the service_on entries throw the frontend port and the protocol into one field (all fields are colon-separated). Sometimes the port is optional, so http is equal to http/80 which makes reading/writing the configuration unnecessarily complicated.
• pagekite.py comes with loads of servers and encryption options, it tries to solve everything at once. Yet it fails at simple tasks like listing its own services, so I wouldn't trust that other functionality too much.
• it's not very active anymore, but there's one fork where somebody is carving out all the servers/encryption that pagekite brings along