Fix dirty attribute changes on update

[nelsonwittwer]

Description

Fixes #1133 and #1037 which both report a substantial issue with tracking what attributes were actually modified by the user since the rest resources were initialized.

The root cause of this issue, as pointed out by @kaarelss, was symbols vs hashes when comparing drift on attributes 🤦 . I also needed to 1) set associations in original_state since our API allows us to modify associated resources and 2) needed to ignore read only attributes in original_state.

How has this been tested?

• Wrote a unit test that reproduced the issue. The fix was then applied to the base rest resource which passed the test.
• In a local environment using this branch of the ruby API library, I found an existing product and updated a single attribute. I compared all other attributes and verified only the single attribute was modified.

Checklist:

• My commit message follow the pattern described in here
• I have performed a self-review of my own code.
• I have added tests that prove my fix is effective or that my feature works.
• I have updated the project documentation.
• I have added a changelog line.

[wayne692]

It's easy

[paulomarg]

Makes sense to me!

[DuncanUszkay1]

This was a breaking change for our application that went unreported in the changelog. We were creating an instance and immediately calling save on it, which with this change resulted in an empty hash being sent to Shopify (since the original state matched the current state after instantiation)

I.E. ShopifyAPI::ObjectName.build(attrs).save! <- this fails now AFAICT

[DuncanUszkay1]

Not sure if we were using the library improperly since I didn't see mention of this is the docs, but if not I can go update the changelog for others who might run into this. cc @nelsonwittwer