[GH-321] Better logging

[rlepinski]

What do these changes do?

This PR does a few things:

• Makes it so apps can override how Airship logs
• Improves filtering by using autoclosure blocks to prevent computing the message
• Bridge all objective-c logs to AirshipLogger so we no longer use NSLog.

How did you verify these changes?

Ran sample app, verified logs are coming through still.

[rlepinski]

Static here. I tried using a lazy computed property but it still caused an issue on iOS 13 and older. Static properties seem fine (they are also lazy).

[SwiftNativeDeveloper]

@rlepinski

Another trick from my "log wrapper" type.

    private var _logger: Any?
    
    @available(iOS 14.0, *)
    private var logger: Logger {
        // swiftlint:disable:next force_cast
        return _logger as! Logger
    }

    private init(subsystem: String, category: String) {
        if #available(iOS 14.0, *) {
            _logger = Logger(subsystem: subsystem, category: category)
        } else {
            // This implementation will do nothing for iOS < 14
            // Implementation of log funcs might make use of Legacy OSLog API but then that presents the 
            // StaticString issue in the API call site
        }
    }

I don't like it and I will remove from my code the moment I can drop iOS 13 support.... but it gets the job done. If you plan to keep it as static var, I'd at least make it private or private(set). It doesn't fix the immutability problem, but it prevents internal classes from trying to change it (even though they wouldn't). I just like protecting code that way.

[rlepinski]

Yeah it should be private let. Not sure which one i like better. You can at least define the subsystem and category on the fly, not that we will. I'll probably just keep it static for now until I have the need for that. Thanks!

[SwiftNativeDeveloper]

I might suggest changing the level for .warn to default.
"Use this level to capture information about things that might result in a failure."

info won't necessarily get saved long term if an issue happens due to internal buffering strategy.
"Use this level to capture information that may be helpful, but not essential, for troubleshooting errors."

I know this approach matches this, but I also disagree with this choice. Warn is higher severity than Notice in SwiftLog terms: https://github.com/chrisaljoudi/swift-log-oslog/blob/master/Sources/LoggingOSLog/LoggingOSLog.swift#L83

I understand this is the default implementation which I will override in my usage, but just something to consider. :)

[rlepinski]

👍

[rlepinski]

Merging into our private repo, will be available next minor release.