docs: clarify when JSON/YAML Properties files were added
New plugin: AWSTags

AWSTags allows querying tags from EC2, and setting groups based on the
tag names or values.
Metadata: better logging when updating XML data fails
testsuite: install boto with optional dependencies
models: handle failure to import plugin gracefully
AWSTags: fixed cache clearing at start of client run
GroupLogic: fixed thread-local variable initialization
Core: Fixed error message on failed altsrc bind
debian: Add build-depends for 35b53c7

Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
Metadata: import any() from Compat
Metadata: read in clients.xml on every write

This ensures consistency between the in-memory representation of
clients.xml and the representation on disk. If we don't read our
writes immediately, there's a race condition when creating a new
client: If it asserts its profile or version before the FAM event from
the clients.xml edit is processed, then the clients doesn't appear to
exist yet, and Bcfg2 complains.
Tests: Fix tests after 9a6a231

The addition of the call to load_xml in 9a6a231 causes the test to
fail because load_xml() expects to read a clients.xml file.  The
actual actual open calls in write_xml are dummied out with Mock,
so no file is written, and thus cannot be read back.  This commit
dummies out the load_xml and adds some more asserts for good measure.
Merge pull request #141 from fennm/fix-unit-tests-after-9a6a231

Tests: Fix tests after 9a6a231
Packages: fixed metadata.Packages["sources"]
schemas: fixed Client/Group tags around MemberOf in POSIXUser tags
bcfg2-lint: allow specifying no lint plugins
Reporting: start a new thread for each import

When dealing with a high-latency database connection (eg. across a
WAN), the bcfg2-report-collector process can fall behind in its
import queue.  The imports are very much bound by the response
latency of the database server and not processing throughput.

This patch fires off a new thread for each database interaction.
The thread itself simply falls out of scope when the interaction
is finished processing.  The interaction object is still read from
the disk serially in order avoid having to create a locking mechanism
for that part of the process.

This change does potentially create greater load on the database
server, but ultimately the load is limited by rate at which the
bcfg2 server can generate work.
Reporting: Simple sanity check to avoid creating too many threads
Merge remote-tracking branch 'upstream/maint' into reporting-thread-each-data-import
Reporting: misc improvements to collector threading

1. Use a better convention for calling the threading.Thread constructor
2. Add docstring to ReportingStoreThread.run
3. Give the storage thread variable a better name