Fix Pulsar's default HTTP transport for poster hacking up urllib.
Behavior of urllib changes with respect of content length of mmap content after poster is loaded - is automatically loaded by Pulsar client as of 9207ecb43d81853da7a58cd5634683dc87991c4f (added as part of October 2014 stable release).

Enis has confirmed this fixes some problems in latest stable.
Bugfix: composite uploads broken by upload common assuming bunch's have a UUID field.
Reported by tjkarlsson@uma.es here http://dev.list.galaxyproject.org/Problem-to-upload-data-to-Galaxy-when-using-pbed-file-format-td4666000.html.
Update tag latest_2014.10.06 for changeset acc8d1e2bc88
Merged in jmchilton/galaxy-central-fork-1/stable (pull request #566)

[STABLE] Fix Pulsar's default HTTP transport for poster hacking up urllib.
Fix to 42b2e53: should be in next-stable
Merge
History, view multiple: show error when anonymous with links to register and log in
Merge next-stable
Merge stable into next-stable.
Merge next-stable into default.
Fixes for /dataset_collections API endpoint.

Guess this is not as utilized as the variant under /histories.
Add helper for waiting on a job instead of a history.
Rename variable for clarity after tools can explicitly create collections.

created_collections is ambigious - these are HDCA for implicitly created collections so renaming this field implicit_collections.
Another variable rename for clarify.
Script to build workflows from simpler YAML description.
Enable explicit tool creation of collections with static or determiniable number of datasets.

By "static" I mean tools such as a FASTQ de-interlacer that would produce a "paired" collection with two datasets everytime. By "determinable" I mean tools that perform N->N operations within the same job - such as a tool that needs to normalize a bunch of datasets all at once and not in separate jobs. (For N->N collection operations that should or can be done in N separate jobs tool authors should just write tools that operate over a dataset and produce a dataset and let the end-user 'map over' that operation.)

There are still large classes of operations where the structure of the output collection cannot be pre-determined - such as splitting files (e.g. bam files by read group) - that are not implemented in this commit.

Model:

The models have been updated to do a more thorough job of tracking collection outputs. Jobs just producing HistoryDatasetCollectionAssociations works fine for simple jobs producing collections - but you don't want to map a list over a tool that produces a pair and produce a bunch of pairs HDCAs and a list:pair HDCA- you just want a bunch of pieces and the one list:pair at that the top.

Workflow:

Workflows containing such operations can be executed - but the workflow editor has not been updated to handle this complexity (and it will require a significant overhaul) so such tools are not available in the workflow editor.

Tool Testing (WIP):

TODO:

Tests:

Includes two tools to test this - one that uses explicit pair output names and one that iterates over the structure of input list to produce an output list.

Includes several new tools API tests that test the tools described above via the API and implicit mapping over such tools. Includes two new workflow API tests - one that verifies a simple workflow with output collections works and one that verifies mapping over workflow steps in collections works.
Prevent tools producing collections from showing in workflow editor.

Certainly feasible someday but workflow editor logic will require significant overhaul.
WIP: Toward dynamically discovered output collections.

Models:

Track whether dataset collections have been populated yet.

Still hoping for dataset collections to be effectively immutable once populated - but dynamic output collections may require them to be sort of likely `final` fields in Java (analogy courtesy of JJ) - allowing them to be declared before they are initialized or populated.