Remove Spree ResourceController callbacks

[Matt-Yorkley]

What? Why?

Removes Spree's custom implementation of additional controller callbacks. We only use this in a couple of places, and they can be easily replaced with regular Rails controller callbacks or simple method calls.

The point of these extra callback hooks is to allow the maximum possible customization by apps using Spree as a gem, without having to modify the source. We're not in that position any more in relation to Spree code, so this extra callbacks layer is essentially a huge mess with no real value.

🔥🔥🔥

What should we test?

• Updating a Schedule: when successfully update, should sync relevant subscriptions as before
• Creating a PaymentMethod: should work correctly when creating a payment method for a hub
• Creating a ReturnAuthorization: should work as before
• Creating a Variant: should create it successfully, and with a valid price

Release notes

Remove Spree's resource controller callbacks implementation

Changelog Category: Technical changes

[mkllnk]

😌 So good!

We have to be careful though. I've seen PRs recently introducing new calls. We have to check all current PR unless we do some deprecation first.

[sauloperez]

Yes, please!! It should be easy to trace if they are still called somewhere even by raising an exception when any of the ActionCallbacks methods are used and see if the build passes. However, it seems we fixed them all according to my git grep results.

You didn't add testing steps @Matt-Yorkley. Perhaps you want to check if these actions are covered by at least controller tests and see if the build is enough.

[luisramos0]

Wonderful PR!!! 👏 👏 👏

[mkllnk]

Well, I found the one PR I remembered that added usage of these callbacks. So this should be fine as long as we keep that in mind when reviewing.

[filipefurtad0]

Hey @Matt-Yorkley ,

Thanks for pointing out the relevant places/test cases for this clean-up 🙏

Tested:

• Updating a Schedule: when successfully update, should sync relevant subscriptions as before - this appears to work just as before. Deleted, created and changed the attribution of schedules to OCs (see additional notes, below).
• Creating a PaymentMethod - all as before
• Creating a ReturnAuthorization - all as before
• Creating a Variant - created a new variant, added to OC, placed an order - all as before this PR

This looks good to go 👍

Additional notes:

While testing schedules/subs I've ran into this one again: #7294 (payments not successful) and this scenario, as reported here

It seems to be possible to delete a schedule (as a workaround for openfoodfoundation/wishlist#283), by removing the schedule from all the previously associated OCs here (clicking the x):

If this is done, then the hub can run into the situation in which a subscription exists, but has no schedule associated with it, although it appears so like it does:

Moving on to check if this was reported already elsewhere; Not related to this PR so -> ready to go!