[Issue #3730] Fix parsing issueType bug

[widal001]

Summary

Fixes the type in the IssueType pydantic model that was causing issueType to be parsed incorrectly.

Fixes #3730

Time to review: 5 mins

Changes proposed

What was added, updated, or removed in this PR.

• Fixes typo in IssueType field alias (it was incorrectly aliased as "type" instead of "issueType")
• Replaces the string literal field aliases with module level constants to make it easier to update and monitor field aliases.

Context for reviewers

Testing instructions, background context, more in-depth details of the implementation, and anything else you'd like to call out or ask reviewers. Explain how the changes were verified.

1. Checkout the PR locally
2. Run make gh-data-export to export the data from GitHub
3. Run the following command to check the percentage of issues that have null value for issue type:

   jq '[.[] | select(.issue_type == null)] | length' data/delivery-data.json

4. The output should be around 691
5. Spot check values in data/delivery-data.json where "issue_type" is null each issue that you check, should be missing a "Type" in GitHub (see screenshot below)

Additional information

Screenshots, GIF demos, code examples or output to help show the changes working as expected.

A major goal for Sprint 2.3 will be to set up some automated data quality checks in both Metabase and the ETL pipeline to prevent or at least catch similar regressions earlier.

[coilysiren]

👍🏽!

[DavidDudas-Intuitial]

Thanks for finding and fixing the root cause of recent data anomalies!

[jcrichlake]

Should we put a unit test in place for these values? To make sure that the values are parsed correctly and not dropped due to an incorrect label?