Change-Id: Ia6e458cda841cec9b7cce930bfcc8214fed07189

mccabe has undergone some very significant bug fixes recently but has
not yet released a new version. When it does, complexity calculations
will change in potentially significant ways.

Cherry-picked onto 0.9.x to make sure a release of mccabe doesn't break
existing 0.9.x users.

Change-Id: I6e75391da19fde45588575517087d1ba4e4c44b7
(cherry picked from commit 7a64968)

When we move modules out of namespace packages we set up redirects to
import the new module under the old name. Python's import machinery
doesn't detect those things as modules, and the names don't show up in
sys.modules. However, if we look at what we actually got when we did the
import we can see that it is a module.

Change-Id: I4b42d081965b6d898b178cbe9232b47cfed17d8a
(cherry picked from commit dd8b4d6)

This commit is backporting commit 64ef5bf. It could not be
cherry-picked, as the unit test code had lot more dependent code to be
pulled in.

Issue: flake8 occasionally encounters "H302  import only modules."
error even though the python module exists at the path and python
shell is able to import the same.

Root-cause: The while loop in is_module_for_sure() had a bug, where
iterating variable, 'mod_name', was getting derived from the same
input, 'mod', every time. It should have led to an infinite loop
otherwise. But, an ImportError takes it out of the loop. Most of
the cases, this is not an issue, if as part of the exception handler,
built-in __import__() finds the module. The evidence of the issue is
the availability of import statements suffixed with "# noqa" to
work-around the bug.

Fixing the while loop causes the logic to flow in the original path of
the code to use 'imp.find_module()'

Change-Id: I421a66242121b987b7c8c1568394478514073b87

Hacking's pbr cap of <1.0 is breaking things (see bug for a lot more
detail). Since projects are still using hacking 0.9.x bump the PBR cap
to unbreak projects still on 0.9.x.

Change-Id: I77f2b7e661c4de067e39596765d36a4463a2d143
Closes-Bug: #1456376
(cherry picked from commit bc4b111)

Unlike most of the other OpenStack projects hacking is not automatically
syncronsed to projecst via the proposal-bot.  My understanding of this
is because new hacking tests could cause unexpected gate failures which
it was automatically syncronised and/or did not always take into account
project style.

The downside of this is that we have alarge number of projects still
using older hacking releases.

This has come to a head with the release of pbr 2.0.0 which conflicts
with 0.9.x and 0.10.x hacking branches.

While it isn't possible to get all projecst up to the newest hacking it
it is possible to remove the cap on PBR and allow project that still
want older hacking releasee to work with the new PBR release.

Change-Id: Iabf27cc0648c12c3c090f01facd15c3ec52a4861
Related-Bug: 1668848

This commit was bulk generated and pushed by the OpenDev sysadmins
as a part of the Git hosting and code review systems migration
detailed in these mailing list posts:

http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html

Attempts have been made to correct repository namespaces and
hostnames based on simple pattern matching, but it's possible some
were updated incorrectly or missed entirely. Please reach out to us
via the contact information listed at https://opendev.org/ with any
questions you may have.