Test: lrmd: fence_dummy_monitor in Python too slow in Travis CI

Because of imaginable resource constraining of VMs with Travis CI
test environments, it is assumed that 10x higher rate of interrupts
introduced with a previous commit bb3a729 (sleep(1) vs. select-based
sleeps of 100ms), together with effectively decreasing the real wait
time from 6s to 5.1s (so as to more truthfully reflect the magic
constant denoting the afforded timeout when fetching metadata from
fence-agents-like stonith agents) is what made get_stonith_metadata
lrmd regression test fail:

Running: lrmd_test -c metadata -C stonith -P pacemaker -T

       fence_dummy_monitor -V
notice: crm_add_logfile: Additional logging available in
                         /var/log/pacemaker.log
  info: crm_log_init:	Changed active directory to
                      /var/lib/pacemaker/cores
  info: main:	Starting

warning: stonith_api_device_metadata: Could not obtain metadata for

      fence_dummy_monitor
info: lrmd_api_disconnect: Disconnecting from 1 lrmd service
info: crm_xml_cleanup: Cleaning up memory from libxml2

STDOUT string 'resource-agent name="fence_dummy_monitor"' was not

found in cmd output

API-CALL FAILURE for 'metadata' api_rc:-5

A simple (and pretty justified) rewrite of agent from Python to shell
turned out to solve this new issue.

Note that it's debatable whether it would be appropriate to make said
magic constant configurable or partially derived from run-time ability
to meet the previous deadlines.