protect against samplerates changes that may screw things up.

while the call is recursive in the change of samplerate case, on the second time
around, we will match, then check to see if we have enough data.

The flv handler was not handling that case well enough and was possibly changing
the buffer even if it was on the queue, it's allowed to when dealing with a private
buffer but not on a shared queue.
make fallback to file handles more permenant. This should help keep stats for inactive mounts

as fallback files were getting setup and dropped on the fly, any mountpoints that were inactive
but had fallback to files configured where getting dropped.  To keep to a standard way of doing
things and because slaves use these stats then we should keep them around but to do so we need
to keep those file handles around by dropping the expire time to something invalid and skip them
during the purge.  They do get purged and recreated (if defined) over reload.
impose an upper limit on 2.x log size setting
make sure the outgoing bitrate stat drops to 0 when last listener detaches from fh
make sure the passthrough stream is accounted for, or else lag will trigger for listeners
trap for the odd case of no mpeg details being set up, prevents null deref crash
Add ${mount} expansion to intro file, on-connect and fallback tag values

While wildcard support in mount-name can be useful, it was limiting for applying settings
for the above where you want to determine the actual result based on the requested mount, now
the ${mount} can be used to apply the option to the values

eg

<mount>
   <mount-name>/live-*</mount-name>
   <intro>/intro/${mount}.mp3</intro>
   <fallback-mount>/backup/${mount}</fallback-mount>
</mount>

With the above, the block can match

/live-64  using intro /intro/live-64.mp3, fallback to /backup/live-64
/live-128 using intro /intro/live-128.mp3, fallback to /backup/live-128

The ${mount} is the mountpoint without the initial / so that you can concatenate the name onto
another such as /backup-${mount} becomes /backup-live-64
in cases with privileged ports over reload, this test was reporting a false error
allow ${mount} expansion in dump file mount setting
prevent fallback loop if no streams are present
smaller scheduling changes. Mostly to prevent a 0 mS wakeup

cases like a failed trylock or dropping an re-acquiring source locks are also in here to
help in reducing wakeups. some thresholds for moving clients around have been increased
to allow for more flexability for balancing across multiple workers.
global listeners count was not decreased in rate limited file requests
fix another inconsistent global listeners count.

This is if you have a rate limited mount going through auth leading to a missing stream and
file.  This case fell through to the 404 handler which returned the wrong code.
make sure the incoming rate is re-evaulatedm so that we don't get stuck in the codepath
stats send updates. not many people using this but the changes here are internal

The key issued fixed here is a possible race where a source could get started between the
stats being generated and the client being added.  now we register the client, so that stats
for new details are added as normal, but the client itself is inactive (therefore no sending)
until the full list is made, and prepended. only then is the client made active. adn woken up

we also avoid the explicit wakeup, it's not required and a manual wakeup on exit is triggered.
This will be more useful later with relays switching masters.
internal name cleanup for consistency.

The idea here is we use the term 'host' inside a relay block, not 'master' like before (although
master is still accepted).  Much of this commit deals with the internal renaming so no actual
usage will differ.
need to clear this setting on relay cleanup.

cannot rely on stat details being still allocated later during the relay
release.
prevent double lock case with fallback lookup. code cleanup only

The spec allows for a double lock, it's just pointless.  There are 2 cases where this is
called so make it consistent and only lock the source tree outside of the fallback lookup.
small parsing fix for query parameters
move override trigger later, when some valid data has arrived

To handle cases wehere some clients start up to feed an override mount but fail to send anything
(usually because there feeds have failed).  By delaying the override of listeners, gaps do not
appear in their feeds. In normal cases the trigger still occurs.

instead of the source_init being used to trigger the override, the first buffer to place on the
queue is used.