feat: add refunds GraphQL query

[kieckhafer]

Part of #5158
Impact: minor
Type: feature

A new listRefunds query allows you to query refunds of payments on a particular order. This was previously a meteor only method. The meteor method will be removed with #5158.

Breaking changes

None

Testing

1. Place an order using both the Stripe payment method and IOU method
2. Create a refund for each type of payment
3. Use the new listRefunds query to see the refunds

listRefunds(orderId: {ORDER-ID}, shopId: {SHOP-ID}) {
   _id
    amount
    ...otherFieldsYouWant
  }

I've added tests here to test the permission / requirements of variables, but did not add tests to check a result, as the payment method has it's own tests for this element: https://github.com/reactioncommerce/reaction/blob/feat-kieckhafer-listRefundsGQLQuery/imports/plugins/included/payments-stripe/server/no-meteor/util/stripeListRefunds.test.js#L10

[kieckhafer]

@aldeed I wasn't sure if this should go into Payments or Orders. I put it in Orders because each specific payment method has it's own way of calculating the refunds, and this is just a list that is displayed on the Orders operator UI. Also, all of the old meteor versions of this are in the Orders package.

What do you think about it's location?

[aldeed]

@kieckhafer I think I have the same thoughts as you, could go either place. Since payments are currently coupled with orders, leaving it in orders seems fine.

I'm assigning @focusaurus to do the full code review here, but my only comment is that for GraphQL, we try to omit words like get and list from the query names. That's pretty standard GQL best practice. So I'd go with just refunds.

Also keep in mind that something like this fits pretty well into the payment resolver. In other words, rather than (or in addition to) Query.refunds resolver, you could have a Payment.refunds resolver. This is nice because you'd already know order ID and payment ID in that resolver, plus you could avoid doing an extra query in Catalyst.

{
  order {
    payments {
      refunds {
        amount
      }
    }
  }
}

Or for a combined list for all payments, it could be similarly done as Order.refunds resolver. There can be several resolvers that all call the same query function giving clients various ways to get the same info.

[kieckhafer]

@focusaurus I added a new query here, refundsByPaymentId, and also added a couple resolvers so that you can query refunds on an order, and also refunds per payment, so there is some additional functionality to check since your last review.

query {
  orderByReferenceId(id: "ORDER-ID", shopId: "SHOP-ID") {
    _id
    payments {
      _id
      method {
        name
      }
      refunds {
        amount {
          displayAmount
        }
      }
    }
    refunds {
       amount {
        displayAmount
      }
      paymentDisplayName
    }
    shop {
      _id
    }
  }
}

[aldeed]

@kieckhafer A few last comments

[kieckhafer]

@aldeed comments addressed, ready for a final look