Delete flight plan with 404 response without a body fails

[punamverma]

Describe the bug
During the cleanup step of scenarios, delete flight plan is executed for all the flight plans in the scenario. Some scenarios like Validation of operational intents have flight plans that do not get planned, as expected. When deletion of such unplanned flight plans is triggered, some USSes respond with 404 response code (Note - Mock USS responds with 200). As per automated testing interface, 404 response code does not need a response body. But in the uss_qualifier tests the client_v1 checks for a response body for a 404 response as well, which is not consistent with the interface spec.

To reproduce
Steps to reproduce the behavior:

1. Go to https://interuss.github.io/monitoring/artifacts/uss_qualifier/reports/utm_implementation_us/sequence/s39.html
2. Click on events 51, 53 and 55.
3. Unplanned flight plans are deleted
4. Mock USS gives a 200 response, but some USSes give 404 in response. And when the 404 response is with out a body, they fail the cleanup step.

Difference from expected behavior
A 404 response without a response body, on deletion of unplanned flight plan should not fail the cleanup step in a test.

Possible solution
Do not check response body for a 404 response on deletion of unplanned flight plans.

System on which behavior was encountered
OS: iOS

Codebase information
Output of git log -n 1: Exists in current codebase.
commit 707dd8f

Output of git status:
NA

[BenjaminPelletier]

I think this identifies a few different problems with the Validation of operational intents test scenario (some problems likely extending to other scenarios):

1. When a 404 response is accepted for DELETE /flight_plans/{id}, the body should not be validated, exactly as Punam describes
   1. This is the wrong thing to check when the response code was 404
   2. Probably try_end_flight is the wrong place to allow 404 -- 404 should probably raise an error, and certain other places should catch and allow that error when it is a 404. It doesn't seem like try_end_flight can actually return a valid PlanningActivityResponse in general when it allows 404.
2. Referring to Punam's s39 link, the "Attempt to plan Too Far Away Flight" step indicates that the flight_plan_status was NotPlanned, yet the Cleanup step still attempts to clean this flight up. I would expect that we would not attempt to clean up flights that were never actually created due to positive rejection
   1. Note: we should still attempt to clean up flights for which we don't know the creation status due to some kind of error (timeout, 503, etc) since those flights may have been created and we didn't know it. But here, we are told explicitly that the flight was not created so there shouldn't be any doubt.
3. mock_uss's 200 response to the deletion of a non-existent flight is inappropriate; it should respond 404.
4. If a USS indicates that the result of attempting to delete a flight was "Failed", that should be noted at a minimum, and probably escalated to an error similar to a failure to clear the airspace

[the-glu]

Hello everyone,

I opened 4 PRs that should fix the issue, based on @BenjaminPelletier 's remarks :)

For point 4 I choose a gentle approach with a simple note, but we can evolve to a real error with others PRs ^^'

[the-glu]

Everything has been merged, so I think that one is closable @punamverma ? Can you verify with current master branch?

[punamverma]

Thanks Maximilien. Yes, the test reports looks good. The tests are not attempting to delete the unplanned flight plans, and hence no 404. Also, I see in your PR that if there is a 404, there is no check for the body. Closing the issue. Thanks.