EDP Simulator Should Handle Requisitions in the Withdrawn State

[kungfucraig]

Recently, a Withdrawn state was added for Requisitions. The EDP Simulator has not been updated to handle this case.

The correct behavior is for the EDP Simulator to handle an Illegal State exception during fulfillment by calling "Get" and then ignoring the exception if the state of the Requisition is withdrawn. Otherwise the exception should be propagated.

Once this issue is fixed, it can serve as an example of how a real EDP should handle this situation.

[SanjayVas]

The correct behavior is for the EDP Simulator to handle an Illegal State exception during fulfillment by calling "Get" and then ignoring the exception if the state of the Requisition is withdrawn. Otherwise the exception should be propagated.

This is not actually the correct behavior, as the caller (EDP simulator) cannot actually determine that the FAILED_PRECONDITION error is due to Requisition state mismatch. The correct behavior would be one of the following:

1. Inspecting the ErrorInfo (see AIP-193) from the Fulfill RPC to see the state.

   This requires plumbing the error info properly through from the Kingdom internal API to Kingdom system API to the Duchy public API, as this primarily happens when fulfilling at the Duchy. This is something that we should eventually do to conform with the AIPs. We currently only plumb ErrorInfo from the Kingdom internal API to the Kingdom public API. Furthermore, that ErrorInfo plumbing is incorrect (see ErrorInfo from Kingdom public API malformed #1919).

2. Passing a Requisition etag in the fulfill request and handling ABORTED errors by retrying at a higher level, i.e. calling Get and checking the state

   This requires the API definition to include an etag field in Requisition and the services to implement AIP-154