Initial work on test cases for history contents API.
Include root folder id in output when creating library.

This prevents the need to hit the API one more time to get the root folder ID before creating datasets/folders/etc... in the library.
Include LDDA state in library dataset to_dict.

Needed to monitor library dataset uploads (in particular for API tests, but really any monitoring will benefit from this).
Infrastructure for library API testing.

Doesn't really test libraries extensively, but adds enough infrastructure to enable a library dataset to history copy test via API.
Start rework of API test mixin TestsDataset into an plain object.

Mirroring the newer WorkflowPopulator and LibraryPopulator.
Rework history.contents_iter to potentially support multiple types.

This is utilized downstream in collections work to allow a similar API to be used for loading HistoryDatasetCollectionAssociations as HistoryDatasetAssociations.
Rework history_contents API to allow room for multiple 'type's of history contents.

Downstream dataset collections are being added and can be associated with histories. They have hids, can be deleted, etc... many of the same properties as HDAs. This refactoring "makes room" for these in the history contents API by allowing type to be passed in.

Since HDAs and HDCAs can have the same id - the path history/{history_id}/contents/{contents_id} is somewhat ambigious - so this changeset adds the path history/{history_id}/contents/datasets/{history_dataset_id} while a matching resource path downstream history/{history_id}/contents/dataset_collections/{history_dataset_collection_id} has been added.

The vanilla contents path remains but should be considered deprecated IMO.

Adding type parameter to history/{history_id}/contents index route - this will always default to dataset for backward compatibility - but downstream can be specified as either dataset, dataset_collection, or "dataset,dataset_collection".
Refactor out optional data selection handling.

Reused a few times downstream for dataset collections.
Dataset collections - models - basics.

Mapping, model definition, database migration, and model unit tests to support database collections.
Dataset collections - models - add history.active_contents.

Get all active datasets and collections ordered together by hid. Used downstream for instance when extracting workflows from histories.
Dataset collections - models - history copying.

Copy history dataset collection associations when histories copied.
Dataset collections - infrastructure glue.

Add an API and service layer for dataset collections.
Dataset collections - tool parameters - basics.

Add parameter, wrapper, etc... to explicitly utilize dataset collections from tools. These require actually modifing tools to take in "data_collection" parameters. Downstream changesets will provide a number of infrastructure enhancements to allow existing tools to "map" and "reduce" dataset collections with existing tool.

TODO: Add tools to test/functional/tools to demonstrate these additions.
Dataset collections - tool parameters - enhanced rerun.

Rerunning tools in same history will work without this, but getting rerun to work on imported histories requires this hack (mirroring the same hack for HDAs in the same file).
Rework logic related to computing selected datasets.

Allow dataset ids to be used. This will make implementing multi-running of tools possible without expanding values out to hdas. check_params will still be called on each permutation so this shouldn't result in security problems.
Refactor Tool.handle_input result to return list of pairs instead of odict.

This added generality of allowing multiple outputs with the same output name will allow handle_input to execute multiple jobs in subsequent changesets.
Allow running tools on multiple datasets simulatenously (backend+API).

Each data tool parameter can be specified via a similar named parameter but with the suffix |__multirun__. This second parameter variant should be a list of datasets - one job will be created for each such dataset.
Allow running tools on multiple datasets simulatenously (UI).

Update tool form. This commit needs work to ensure this only affects the tool_form.mako.
Add tool meta parameter exception.
Dataset collections - "map" with existing tools (backend).

Allow replacing data parameter inputs with collections - this will cause the tool to produce multiple jobs for the submission - one for each combination of input parameters.