Fix linting errors in GitHub Actions build test workflow

[jennantilla]

Description

One Line Summary

Fix linting errors in GitHub Actions build test workflow

Details

Motivation

New PRs were failing the GitHub Actions build test due to linting errors.

Steps to fix the issue:

• Update ktlint plugin org.jlleitschuh.gradle.ktlint to latest version (11.6.1)
• Run ./gradlew ktlintFormat to auto-fix errors
• Manually fix any errors that could not be auto-fixed

The errors that were manually fixed included these ktlint rules:

• max-line-length: increased to 500 in ktlint build.gradle configuration blocks (all modules)
• property-naming: replaced certain property names with camel case and screaming snake case according to Kotlin rules
• Remove wildcard imports: imported individually instead
• Move inline comments to preceding line: linter disallows inline comments

Scope

All modules of OneSignal were impacted:

• core
• notifications
• location
• in-app-messages

Testing

Manual testing

Final run of ./gradlew ktlintCheck --console=plain pass with no additional errors. Example app successfully builds and runs with no errors.

Functionally tested the following actions in example app to ensure no issues:

• Subscribing
• Location prompting
• Receiving notifications
• Receiving In-App Messages
• Tagging
• Sessions

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[emawby]

Looks good! Have we done any functional testing with these changes to validate things build and run as expected?

[jennantilla]

Yes! Updating PR comment with functional testing results.