nfv_client returns None instead of Internal Errors

[Al Bailey]

Brief Description
-----------------
During a kubernetes rootca update orchestration, the services are restarted.
This causes the vim api to be restarted, and can return a socket error if something is querying
the vim api at that time.

This has the unfortunate side-effect of the API returning successfully, but returns a None value rather than reporting the error.

The bug is in the 'error' reason extraction code. it 'returns' when it is supposed to 'break' from the loop.

(I am referring to a previous branch, since this will soon be fixed in the current branch)

https://github.com/starlingx/nfv/blob/r/stx.5.0/nfv/nfv-client/nfv_client/openstack/rest_api.py#L94

Severity
--------
Minor

Steps to Reproduce
------------------
Its difficult to reproduce.
The easier way is to loop and repeatedly query the API, while repeatedly restarting the API.

Expected Behavior
------------------
The error should be reported as part of the query.

Actual Behavior
----------------
The query returns None. When performing a GET, this can make the code think the object has been deleted, when in fact, there is an internal error.

Reproducibility
---------------
Rare

System Configuration
--------------------
Any

Branch/Pull Time/Commit
-----------------------
The bug has been there for over 3 years. Its rare and 'sneaky'

Last Pass
---------
Not Applicable, due to the sneakiness

Timestamp/Logs
--------------
N/A

Test Activity
-------------
Feature Testing

Workaround
----------
Its so random and in-frequent, running the test again will typically work.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/starlingx/nfv/+/817115

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/starlingx/nfv/+/817115
Committed: https://opendev.org/starlingx/nfv/commit/515c22944d93695623e78cb610ce55728329218d
Submitter: "Zuul (22348)"
Branch: master

commit 515c22944d93695623e78cb610ce55728329218d
Author: albailey <email address hidden>
Date: Mon Nov 8 15:50:21 2021 -0600

    Propagate unexpected errors from nfv client

    The code that was iterating over unexpected errors would
    accidentally 'return' rather than raise the error during
    the area where it extracts a reason from the exception.

    This meant that if the API returned an internal error (500)
    the code would mistakenly treat the result as a None response.

    This was particularly troublesome when performing GET operations.

    Now it reports the error and allows the exception to be raised.

    Test Plan:
      PASS: Verify the CLI reports an error when invoked while the API
    is beng restarted.
      PASS: Verify the CLI returns a valid value when invoked under
    normal circumstances.
      PASS: Verify the API reports an error rather than None when a
    strategy is queried during an API restart.

    Closes-Bug: 1950207
    Signed-off-by: albailey <email address hidden>
    Change-Id: I7dc62b28425f09edabf2e6e4914aebc013da3cf4