Metadata: Don't update XML on gratuitous profile update

Check to see if the profile that is being set by set_profile
exactly matches the existing profile list.  If it does, then avoid
writing out a new clients.xml. This simple optimization reduces
the amount of clients.xml rewriting that occurs if you have a
bunch of clients running bcfg2 -p at the same time (for example,
during a cluster rebuild).
Make pylint happy
Found a stray write that should be part of the new client case
Adjust test

Don't need to check write() because update_client() calls it
Make updating the structures conditional on profile changing

Based on the expectations of the tests, I am reasonably confident
that updating the in memory structures is logically part of changing
the client's profile so I put it in the if block
bcfg2-report-collector: removed extra slash from init script
bcfg2-yum-helper: fully download group metadata during makecache
bcfg2-yum-helper: disable pylint check
Core: log when a cached metadata object is used
MultiprocessingCore: log some messages as debug, not error
Plugin: quiet down set_debug, but keep it useful
Probes: expire metadata cache after loading data
Probes: properly clear cache

When reloading probe groups/data for a single client from the
database, only clear data for that client, not for all clients.
Get profile by building metadata instead of guessing

Rather than doing some ad-hoc lookups of internal data structures
stpierre suggested that it'd be better to use the normal metadata
build procedures.  This implements that and adjusts the tests.
Merge pull request #130 from fennm/metadata-dont-update-xml-on-gratuitous-profile-update

Metadata: Don't update XML on gratuitous profile update
Plugin: fixed tests on Debuggable.set_debug
testsuite: install pylint < 1.0, which still has some bugs
doc: Remove deprecated PostInstall entry

Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
Packages: cache group and package selections
Plugin: added new Caching interface

This gives a single unified interface for expiring caches, no matter
the plugin.  This will be particularly useful with the
MultiprocessingCore, as certain calls must be dispatched to child
processes to expire their caches.