Add lower casing in stg_shopify__metafield fields to avoid metafield errors

[fivetran-avinash]

PR Overview

This PR will address the following Issue/Feature:
#64

This PR will result in the following new package version:

0.8.3

Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:

• Lower casing metafield_reference field in stg_shopify__metafield to fix metafield table breakages upstream when the key field has different casing for otherwise identical strings.
• Lower casing owner_resource field in stg_shopify__metafield to ensure identical value fields with different casing are then correctly pivoted together upstream in the shopify transformation package get_metafields macro.

PR Checklist

Basic Validation

Please acknowledge that you have successfully performed the following commands locally:

• dbt compile
• dbt run –full-refresh
• dbt run
• dbt test
• [N/A] dbt run –vars (if applicable)

Before marking this PR as "ready for review" the following have been applied:

• The appropriate issue has been linked and tagged
• You are assigned to the corresponding issue and this PR
• BuildKite integration tests are passing

Detailed Validation

Please acknowledge that the following validation checks have been performed prior to marking this PR as "ready for review":

• You have validated these changes and assure this PR will address the respective Issue/Feature.
• You are reasonably confident these changes will not impact any other components of this package or any dependent packages.
• You have provided details below around the validation steps performed to gain confidence in these changes.

Our development data is limited for testing, but the most important thing is to show that the before-and-after result in stg_shopify__metafield and `shopify__shop_metafields.sql is the same. You will want to test the master and the current branch against each other to validate the results hold. Since the customer has already tested out one of these changes on their own side, this should be enough to validate these changes will achieve the intended result.

See the Height ticket for more details.

Standard Updates

Please acknowledge that your PR contains the following standard updates:

• Package versioning has been appropriately indexed in the following locations:
  • indexed within dbt_project.yml
  • indexed within integration_tests/dbt_project.yml
• CHANGELOG has individual entries for each respective change in this PR
• [N/A] README updates have been applied (if applicable)
• [N/A] DECISIONLOG updates have been updated (if applicable)
• [N/A] Appropriate yml documentation has been added (if applicable)

dbt Docs

Please acknowledge that after the above were all completed the below were applied to your branch:

• docs were regenerated (unless this PR does not include any code or yml updates)

If you had to summarize this PR in an emoji, which would it be?

⬇️

[fivetran-reneeli]

Very minor, but I think typically when we list multiple changes for 1 PR, we lead with the PR

So "PR #69 includes the following fixes:"

[fivetran-avinash]

Changed around!

[fivetran-reneeli]

Looks good, save for a minor syntax thing in the changelog, so I'll set to approve