Proposal: Add support for issue priority

[lukeredpath]

I think it would be useful - for custom reporters mainly - if issues had the concept of a level or priority. Whilst the built-in reporters would likely not make use of it (potentially the runtime reporter could adjust its OS log level though), a reporter that uploads issues to a third-party bug tracking system for example, might be able to map low-priority issues to an "info" or "warning" level and high priority issues to "error" or "fatal".

We recently refactored all of our error handling code to use reportIssue and its great to have a unified interface - we use a custom reporter to upload errors to Sentry.io, but there are often issues that are lower priority and should be reported in Sentry more like warnings but there's currently no way to achieve this.

I'd be happy to open a PR for this but wanted to open this discussion first for feedback.

Proposed API

The reportIssue and any other function that can be used to capture errors would be enhanced with a new priority: parameter.

enum IssuePriority {
  case `default`
  case low
  case high
}

// For example:
reportIssue("This is just a warning", priority: .low)

I've opted for a simpler definition of priority - an alternative would be to mimic something like OSLog or SwiftLog's log levels (e.g. info, warning, error, fatal, debug etc.) but this seems a bit unnecessary to me. I feel the above values are enough to be usable. If more information needs to be communicated, it could be done with a custom error type that has additional metadata.

All functions that have a priority parameter added will default to the default priority.

This would be a non-breaking change for most users of the library. The only exception may be the change to the IssueReporter protocol to include the parameter although it may be possible to maintain backwards-compatibility here using a protocol extension, keeping the old definitions and adding deprecation notices.

[agarrharr]

I achieved a similar thing by making a dependency. I called it remoteIssueReporter and it has one function called log. The live value calls reportIssue and if it's not running in debug mode, it also calls Firebase Crashlytics.