Filter out deleted images from storage usage

All database API's currently include deleted images in the calc of
storage usage. This is not an issue when deleted images don't have
locations. However, there are cases where a deleted image has deleted
locations as well and that causes the current algorithm to count those
locations as if they were allocating space.

Besides this bug, it makes sense to not load deleted / killed /
pending_delete images from the database if we're actually not
considering them as valid images.

The patch also filters out deleted locations.

NOTE: In the case of locations, it was not possible to add a test for
the deleted locations because it requires some changes that are not
worth in this patch. In order to mark a location as deleted, it's
necessary to go through the API and use a PATCH operation. Since this is
a database test, it doesn't make much sense to add API calls to it.
Calling the image_destroy function with an empty location list will
remove all the locations which won't help testing that specific case.

I'll work on a better solution for that in a follow-up patch.

DocImpact:

    The patch now excludes deleted images from the count, this fixes a
    bug but changes the existing behaviour.

    The patch excludes images in pending_delete from the count, although
    the space hasn't be freed yet. This may cause the quota to be
    exceeded without raising an error until the image is finally deleted
    from the store.

Conflicts:
	glance/tests/functional/db/test_sqlalchemy.py

Closes-Bug: #1261738
(cherry picked from commit b35728019e0eb89c213eed7bc35a1f062c99dcca)
Change-Id: I82f08a8f522c81541e4f77597c2ba0aeb68556ce
Merge "Filter out deleted images from storage usage" into stable/havana