Fulfillment orders fulfillment cancellation request

[karmakaze]

This PR adds the following POST requests:

POST fulfillment_orders/:fulfillment_order_id/fulfillment_request
POST fulfillment_orders/:fulfillment_order_id/fulfillment_request/accept
POST fulfillment_orders/:fulfillment_order_id/fulfillment_request/reject

POST fulfillment_orders/:fulfillment_order_id/cancellation_request
POST fulfillment_orders/:fulfillment_order_id/cancellation_request/accept
POST fulfillment_orders/:fulfillment_order_id/cancellation_request/reject

GET requests are in PR #633
Actions move, cancel, close for fulfillment orders are in PR #635
Subsequent PRs will add other fulfillment order related POST requests to relevant resources.

Since all that's really needed is the fulfillment_order_id, if it's known you can do (rather than querying it first):

  FulfillmentOrder.new(id: <the-fo-id>).fulfillment_request(<params>)

Note to reviewer:

• when the endpoint returns a single resource, it is loaded into the current resource and true is returned if the request is ok
• when the endpoint returns multiple keyed resources (e.g. original_fulfillment_order, submitted_fulfillment_order, unsubmitted_fulfillment_order) the return value is a hash of the multiple resources keyed by the names. Is it conventional to reload the current resource with one of these as well?

[froot]

A small change and a couple of nits to keep the tests consistent to the actual API behaviour. Otherwise, looks good!

[froot]

Tested with postman, and sending a JSON body with { "fulfillment_order_line_items": null } will result in the expected behaviour of not setting the fulfillment_order_line_items key at all. Likewise with message.

Great work @karmakaze

[linzhao125]

Looks great!