feat!: Add WITHDRAWN state to Requisition

[SanjayVas]

This change should generally be safe for DataProvider integrators:

• The common ListRequisitions request includes a filter for Requisition.State.UNFULFILLED
• Barring the above, any code that deals with protobuf enums is expected to gracefully handle unrecognized values.
  • For example, Java generated code includes an UNRECOGNIZED value for every protobuf enum.

[wfa-reviewable]

This change is 

[stevenwarejones]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @SanjayVas)

---

src/main/proto/wfa/measurement/api/v2alpha/requisition.proto line 187 at r1 (raw file):

    // `measurement` will be in the `FAILED` state.
    REFUSED = 3;
    // The `Requisition` has been withdrawn. Terminal state.

should this be

The `Requisition` has been withdrawn by a party other than the `DataProvider`. Terminal State.

Also, this will mean that the measurement will be in the FAILED state, correct?

[stevenwarejones]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @SanjayVas)

---

src/main/proto/wfa/measurement/api/v2alpha/requisition.proto line 187 at r1 (raw file):

Previously, stevenwarejones (Steven Ware Jones) wrote…

should this be

The `Requisition` has been withdrawn by a party other than the `DataProvider`. Terminal State.

Also, this will mean that the measurement will be in the FAILED state, correct?

my wording makes an assumption that the operator may want the ability to withdraw. If we don't want to cover that use case for now, we could just comment that this means it was withdrawn by the MC.

[SanjayVas]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @stevenwarejones)

---

src/main/proto/wfa/measurement/api/v2alpha/requisition.proto line 187 at r1 (raw file):

Previously, stevenwarejones (Steven Ware Jones) wrote…

my wording makes an assumption that the operator may want the ability to withdraw. If we don't want to cover that use case for now, we could just comment that this means it was withdrawn by the MC.

The existing wording is correct, IMO. The DataProvider cannot withdraw a Requisition themselves, as is apparent by the lack of a WithdrawRequisition method. They can instead refuse.

This intentionally does not enumerate all the conditions that can result in a Requisition being withdrawn. At the moment, this can happen any time the Measurement transitions to FAILED or CANCELLED. This is not limited to MC cancellation, and can include a different EDP refusing their Requisition, a Duchy indicating a failure, etc.

[stevenwarejones]

Reviewed 1 of 1 files at r1.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @SanjayVas)

[SanjayVas]

Dismissed @stevenwarejones from a discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @SanjayVas)