Volume list queried by error state should contain error_managing state

When we fail to manage a volume, we use cinder list to view the volume list, or use cinder show to view the volume details, We can see that the volume state is error.
   But when we filter the list of volumes by specifying the status as error,We found that there were no manage failed volumes in the screening results.

   This is because the state of the volumes in which the manage failed is error_managing in the database, and in
https://github.com/openstack/cinder/blob/master/cinder/api/v2/views/volumes.py#L62, in line 62 ,that is why cinder list or cinder show
tell us the state of manage failed volume is error, but not error_managing.

  I think this will confuse the user,user may not care whether the state of the volume is error or error_managing，We only distinguish the error_managing state when deleting volumes. if the state of volume is error_managing_deleting, we will not to subtract quota,because if a volume failed to managed, It also did not increase quota occupancy, Since the user sees the state of failed managed volume is error(error_managing in database), then i think error_managing should be included when querying volumes with an error status.
    To query creating or deleting status of volumes as same, should contain managing or error_managing_deleting.

Background
----------

To fix a quota computation issue described in https://bugs.launchpad.net/cinder/+bug/1504007, some internal volume statuses were introduced: 'managing', 'error_managing', and 'error_managing_deleting'.
(We will call these the "managing statuses".)

The managing statuses were intentionally *not* exposed in the REST API, and do not occur in the list of possible volume statuses: https://opendev.org/openstack/cinder/src/commit/f0a3ea02465752f8d22d6b19d80f6ef084757a17/api-ref/source/v3/volumes-v3-volumes.inc#L19-L61
So as far as operator/end-users are concerned, these statuses do not exist.

This is implemented in the cinder.api.v2.views.volumes.ViewBuilder class (which is the base class of cinder.api.v3.views.volumes.ViewBuilder). What it does is map the managing statuses to "official" statuses as follows:
'managing': 'creating',
'error_managing': 'error',
'error_managing_deleting': 'deleting',
so that only the "official" status will appear when a volume with one of the managing statuses is displayed.

As a result, if a user does:
GET /v3/{project_id}/volumes
GET /v3/{project_id}/volumes/detail
GET /v3/{project_id}/volumes/{volume_id}
the user can see a volume that's in a managing status, it's just that the status will be displayed as either 'creating', 'error', or 'deleting'.

The problem
-----------

A user makes the GET /v3/{project_id}/volumes/detail call and notices x volumes in 'error' status. The user then makes the call
GET /v3/{project_id}/volumes/detail?status=error
and receives a list of y volumes, where y < x.

The "missing" volumes are in the internal 'error_managing' status.
If the user picks one of the volumes in x but not y, and does a
GET /v3/{project_id}/volumes/{volume_id}
the volume shows as having status 'error'. (A similar problem occurs if a user filters on status 'creating' or 'deleting'.)

This is confusing.

The situation
-------------

(1) Volumes in managing statuses are already displayed to end users as being in an "official" status. In other words, we already decided back in September 2016 with Change-Id I5887c5f2ded6d6a18f497a018d5bf6105bc5afd7 that for the purposes of the REST API, a volume with internal status 'managing' was "really" in the status 'creating', and the same for the other managing statuses.
(2) When a user filters the volume list on status=error, they should see all volumes that are considered in error status from the REST API point of view regardless of what the purely internal status of the volume is.

Since it's a bug, I don't think that fixing this requires a special flag be added to the API or a microversion. In fact, if an end user can make the call:
GET /v3/{project_id}/volumes/detail?status=error_managing
and get only the volumes with internal status 'error_managing' (though they'll be displayed as 'error'), then that is also a bug, because as far as the REST API is concerned, there is no such status. This same bug covers these:
GET /v3/{project_id}/volumes/detail?status=managing
GET /v3/{project_id}/volumes/detail?status=error_managing_deleting
These calls should not return any volumes, there are no such statuses.

Note that using microversion 3.34,
GET /v3/{project_id}/volumes/detail?status~=error
should (properly) return the volumes in 'error_managing' (though they will be displayed as 'error'). It will also pull up volumes in internal status 'error_managing_deleting' (though they will be displayed as having status 'deleting', and should not actually be included in the response; this is the third bug associated with this issue).

OK, so what needs to be fixed?

(A) when a user filters on status=error, volumes in (internal) status error_managing should also be included
(B) when a user filters on status=creating, volumes in (internal) status managing should also be included
(C) when a user filters on status=deleting, volumes in (internal) status error_managing_deleting should also be included
(D) when a user filters on any status that's not in the official list, they should get an empty list of volumes (need to verify that's the current behavior, but I'm pretty sure that if you GET /v3/v3/{project_id}/volumes/detail?status=not-a-status you get the response { "volumes": [] }, not a 400). Currently we rely on the database for this, but we may need to handle it in the REST API layer.
(E) fixing the "like" operator from microversion 3.34 is going to be tricky. ?status~=error should include volumes in statuses error, error_deleting, error_backing-up, error_restoring, and error_extending (and error_managing), but NOT include volumes with status error_managing_deleting. ?status~=creating should include volumes with (internal) status 'managing'. ?status~=deleting (I think) probably works as expected. I think the "like" operator is handled in the DB layer right now.