Add comments, make comparison less strict

Using `assertIsInstance` should allow the intent of the test to be validated
without worrying about implementation issues like "does the mock library swap
out objects under the hood?"
Merge pull request #1538 from Ichimonji10/fix-test

Add comments, make comparison less strict
Merge pull request #1540 from kbidarkar/fix-taskid

publish and promote function related to cv now return tas_id.
Make test more strict

PR #1538 was made in an attempt to get PR #1536 to pass. That was a mistake, as
PR #1536 is broken.

Revert ea7c20d3983507b655cd8d6e9e77461a1b0d32da
Merge pull request #1539 from Ichimonji10/make-test-strict

Make test more strict
Added new `subscriptions` path for Organization.

Added a new `subscriptiond` path for `entities.Organization` to
facilitate tests that need to fetch what subscriptions are available to
a given organization. Also added tests.

Finally, I updated docstrings replacing ``:return:`` entries with the
correct value of ``:returns:`` and disabled some pylint directives.
Merge pull request #1536 from omaciel/add-subscriptions-api

Added new `subscriptions` path for Organization.
Add a test targeting BZ 1151220

Clients must submit a nested hash of attributes to certain API URLs.

For example, POSTing this data to the `/architectures` URL will succeed:

    {'name': 'foo'}

However, these operating system IDs will be silently ignored:

    {'name': 'foo', 'operatingsystem_ids': [1, 2, 3]}

A client can hack around this oddity by wrapping submitted data inside an extra
hash:

    {'architecture': {'name': 'foo', 'operatingsystem_ids': [1, 2, 3]}}

This extra hash should not be necessary. It makes the API harder to use, and
the extra hash is only required for some API calls.
Merge pull request #1541 from Ichimonji10/bz-1151220

Add a test targeting BZ 1151220
Add test targeting BZ 1151240

Some API responses contain a list of IDs, and others contain a list of hashes.

For example, a GET request to `/gpgkeys/:id` returns data in this format:

    {u'name': u'foo', u'organization': {u'name': u'ACME', u'label': '...'}}

No organization ID is listed. This means that it is impossible to discover what
organization this GPG key belongs to except by issuing a follow-up search to the
`/organizations` URL (and hopefully coming up with only one result).

As a second example, a GET request to `/architectures/:id` returns data in this
format:

    {
        u'name': u'i386',
        u'operatingsystems': [
            {u'id': 1, u'name': u'rhel65'},
            {u'id': 2, u'name': u'rhel7'},
        ]
    }

This is awkward. In this case, the client can compile a list of associated
operating systems by iterating through the returned hashes and fetching through
their IDs. It is much easier to deal with a straight list of IDs:

    {u'name': u'i386', u'operatingsystem_ids': [1, 2]}

The API should return either an ID or a list of IDs for all foreign key
relationships. Client code can be simple and straightforward if a list of IDs is
returned.
Added API tests for Docker images.

Added two new API tests for creating repositories that use Docker
content.

**NOTE**: To synchronize a ``Docker`` image, the ``name`` of your custom
  repository **must** match (case matters) the name of the Docker image.
  For example, the
  [WordPress](https://registry.hub.docker.com/_/wordpress/) image would
  require that your repository name be ``wordpress`` as it is displayed
  in its URL.
Merge pull request #1550 from omaciel/docker-api

Added API tests for Docker images.
Added UI tests for Docker images.

Added two new UI tests for creating repositories that use Docker
content. Please see #1550 for more information about naming conventions
for Docker repositories.

Both tests passed against today's nightly build.
Merge pull request #1551 from omaciel/docker-ui

Added UI tests for Docker images.
Merge pull request #1545 from Ichimonji10/bz-1151240

Add test targeting BZ 1151240
End to end api smoke test

Steps involved:
1. Create new organization and environment
2. Clone and upload manifest
3. Sync a RedHat repository
4. Create content-view
5. Add repository to contet-view
6. Promote/publish content-view
7. Create an activation-key
8. Add product to activation-key
9. Create new virtualmachine
10. Pull rpm from Foreman server and install on client
11. Register client with foreman server using activation-key
12. Install rpm on client
Merge pull request #1546 from sghai/smoke-api

End to end api smoke test
Remove unused iniparse requirement
Merge pull request #1559 from elyezer/update-requirements

Remove unused iniparse requirement
Update smoke test for available URLs

Rewrite `TestAvailableURLs.test_get_links` to match the response currently
generated by the API.

[BZ 1105773](https://bugzilla.redhat.com/show_bug.cgi?id=1105773) was marked as
VERIFIED on the 10th. As a result, the `skip_if_bug_open` decorator now allows
the test to run. The test expects a flat list of URLs from the API:

    u'/katello/api/content_views/:content_view_id/content_view_puppet_modules',
    u'/katello/api/content_views/:content_view_id/filters',
    u'/katello/api/content_view_versions',
    u'/katello/api/environments',
    u'/katello/api/errata',
    u'/katello/api/gpg_keys',
    u'/katello/api/host_collections',
    u'/katello/api/organizations',
    u'/katello/api/organizations/:organization_id/content_views',
    …

The test was created quite some time back, and in the meantime the API has been
changed. The API actually returns data in this format:

    {u'content_views': {
        u'…': 'u/katello/api/content_views/:id',
        u'…': 'u/katello/api/content_views/:id',
        u'…': 'u/katello/api/content_views/:id',
        u'…': 'u/katello/api/content_views/:id/available_puppet_module_names',
        u'…': 'u/katello/api/content_views/:id/available_puppet_modules',
        u'…': 'u/katello/api/content_views/:id/copy',
        u'…': 'u/katello/api/content_views/:id/environments/:environment_id',
        u'…': 'u/katello/api/content_views/:id/history',
        u'…': 'u/katello/api/content_views/:id/publish',
        u'…': 'u/katello/api/content_views/:id/remove',
        u'…': 'u/katello/api/organizations/:organization_id/content_views',
        u'…': 'u/katello/api/organizations/:organization_id/content_views',
    }, …}

The keys in the outer dict are names like "content_views" or "architectures".
The keys in the inner dict are prose descriptions of corresponding paths.

Fix #1555.