master: add a custom step field in dynazoom

With the advent of supersampling plugins, we can have sub-5min values. This
also means that the resolution might change when zooming. Usually this is the
desired behavior, but sometimes we want the averaged value.

Leaving it empty stays as previously : it uses the finest precision available.
cgi-graph: also accept csv & json extensions
cgi-graph: Adding csv output
cgi-graph: adding json output
cgi-graph: adding xml output
cgi-graph: fix typo
cgi-graph: fix xml output
templates: fix overview missing tag
fix plugins.history
getversion: Handle checked out tags better
plugins/df: update exclude list doc to match code

This was insired by D#694531
plugins/snmp__df: find all mount points

The snmp__df plugin does not properly find all mount points on monitored
system. The problem is on line 138, where it processes keys, but should
rather work with values.

... followed by ...

Actually I ended up with removing all storage logic and checked only
for partitions.

Closes: D#671448
plugins/bind9_rndc: fix if named.stats is on tmpfs

In a situation where bind9 named.stats is on tmpfs, the file wont exist after a
reboot until 'rndc stats' is run. Since the plugin opens the file prior to
running the command, the plugin will exit with a file not found error.

Patch simply tests if the file can be read, if not, issues an extra 'rndc
stats' before opening.
plugins/cpuspeed: fix if cpus are at maximum speed

According to janning <vygen@kicktipp.de>:

-------
If you are running your cpus at maximum speed (like with governor performance
in /etc/default/cpufrequtils) the calculation fails. The plugin counts cpu
cycles. It then calculates the difference to the last mesured cycles dividing
by the 5 minutes (as munin is called every 5 minutes).  thats fine BUT, the
plugin is configured to have a maximum value which is the same as the maximum
top frequency of your cpus.  If you are running your cpu at top speed the
calculated value is hitting the max value, maybe just because the time
calculation is not accurate. if the measurement contains 5 minutes and 2
seconds but the calculation is based on 5 minutes, you have to many cpu cycles.
munin does not show values beyond max_value. So you don't see anything in your
graph.

Just adding extra 10% to max_value as a safety area should solve the issue.
-------

The fix implemented has the same logic, but is pure /bin/sh

Closes: D#615957
Disable server-side prepared statements for pg plugins

We'll only ever run our queries once per connection anyway, so there
is no benefit from the prepare itself - just the cost of additional
roundtrips as well as cluttering statistics tools on the server side.
getversion: update doc
getversion: use the commit SHA instead of tree SHA

Fix according to spec
getversion: prefix the commit with "-g" magic

As "git describe", we also use the "-g" magic string to denote a git hash.
getversion: apply the changes described in doc
getversion: also fix the stable-* rules