Packages: fixed metadata.Packages["sources"]
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
Revert "Reporting: Simple sanity check to avoid creating too many threads"

This reverts commit f813f86f8ac2bc7b55f4eb6a0d936f1ce4f68ba7. Premature
optimization is the root of all evil, etc.

Conflicts:
	src/lib/Bcfg2/Reporting/Collector.py
Merge pull request #142 from fennm/reporting-thread-each-data-import

 Reporting: start a new thread for each import
testsuite: install django 1.4.8 when testing py 2.5
testsuite: remove duplicate django installation
specfile: backported merge w/ Fedora specfile to 1.3