Update git submodules

* Update cinder from branch 'master'
  - Merge "Introduce flake8-import-order extension"
  - Introduce flake8-import-order extension
    
    This adds usage of the flake8-import-order extension to our flake8
    checks to enforce consistency on our import ordering to follow the
    overall OpenStack code guidelines.
    
    Since we have now dropped Python 2, this also cleans up a few cases for
    things that were third party libs but became part of the standard
    library such as mock, which is now a standard part of unittest.
    
    Some questions, in order of importance:
    
    Q: Are you insane?
    A: Potentially.
    
    Q: Why should we touch all of these files?
    A: This adds consistency to our imports. The extension makes sure that
       all imports follow our published guidelines of having imports ordered
       by standard lib, third party, and local. This will be a one time
       churn, then we can ensure consistency over time.
    
    Q: Why bother. this doesn't really matter?
    A: I agree - but...
    
    We have the issue that we have less people actively involved and less
    time to perform thorough code reviews. This will make it objective and
    automated to catch these kinds of issues.
    
    But part of this, even though it maybe seems a little annoying, is for
    making it easier for contributors. Right now, we may or may not notice
    if something is following the guidelines or not. And we may or may not
    comment in a review to ask for a contributor to make adjustments to
    follow the guidelines.
    
    But then further along into the review process, someone decides to be
    thorough, and after the contributor feels like they've had to deal with
    other change requests and things are in really good shape, they get a -1
    on something mostly meaningless as far as the functionality of their
    code. It can be a frustrating and disheartening thing.
    
    I believe this actually helps avoid that by making it an objective thing
    that they find out right away up front - either the code is following
    the guidelines and everything is happy, or it's not and running local
    jobs or the pep8 CI job will let them know right away and they can fix
    it. No guessing on whether or not someone is going to take a stand on
    following the guidelines or not.
    
    This will also make it easier on the code reviewers. The more we can
    automate, the more time we can spend in code reviews making sure the
    logic of the change is correct and less time looking at trivial coding
    and style things.
    
    Q: Should we use our hacking extensions for this?
    A: Hacking has had to keep back linter requirements for a long time now.
       Current versions of the linters actually don't work with the way
       we've been hooking into them for our hacking checks. We will likely
       need to do away with those at some point so we can move on to the
       current linter releases. This will help ensure we have something in
       place when that time comes to make sure some checks are automated.
    
    Q: Didn't you spend more time on this than the benefit we'll get from
       it?
    A: Yeah, probably.
    
    Change-Id: Ic13ba238a4a45c6219f4de131cfe0366219d722f
    Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>

cinder

@@ -1 +1 @@
-Subproject commit 2eae3a048901aeb8b22bd575b17f3e4cbfc8a4ea
+Subproject commit 7c872970f99f515e0a8ecf9fcd729295c4917988