add configuration option to persist user information between launches

[robinmacharg]

Goal

Add persistence of set user info (id, email, name) between notifier instantiation.

Design

This stores the three pieces of info in the keychain to assuage any privacy/security concerns (primarily desktop since mobile devices are typically single user). SSKeychain is used for keychain access to simplify the notifier code.

Persisted (or deleted) user data operations percolate to BugsnagConfiguration.metadata appropriately.

Atomicity of operation has been ensured via @synchronized.

In persistUserData() the simplicity and readability of if/then/else has been preferred over the terseness (and, questionably, elegance) of a ternaries' ?:.

There has been significant discussion around how to test this feature. See below.

Changeset

• Primarily changes to BugsnagConfiguration
• Added SSKeychain source files
• Significant effort went in to testing (see below)

Tests

Unit tests fail due to missing entitlements. Entitlements - required for Keychain access - are only generated for applications, not libraries/frameworks. Adding a separate stub application to associate with the unit tests was deemed the incorrect approach due to potential issues over signing, and failing preexisting tests. The test functionality was instead moved into CI tests. The unit tests were left in place, heavily documented (and commented-out appropriately) to highlight this issue and to assert test coverage where it is known for a fact. The CI project (maze-runner) also received a small update to add a missing assertion.

SSKeychain was not tested due to its maturity and prior use.

Review

Outstanding Questions

• This pull request is ready for:
  • Initial review of the intended approach, not yet feature complete
  • Structural review of the classes, functions, and properties modified
  • Final review

• The correct target branch has been selected (master for fixes, next for
  features)
• Consistency across platforms for structures or concepts added or modified
• Consistency between the changeset and the goal stated above
• Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• Usage friction - is the proposed change in usage cumbersome or complicated?
• Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• Concurrency concerns - if components are accessed asynchronously, what issues will arise
• Thoroughness of added tests and any missing edge cases
• Idiomatic use of the language

[kattrali]

A couple of top level things:

1. The podspec should include Security framework in frameworks
2. Vendoring the dependency is fine, but the top level symbols will need to be prefixed in case someone's podspec also includes the same library. A quick glance says those would be an enum, a few string constants, and the class name

[robinmacharg]

Thanks for the feedback.

1. The podspec should include Security framework in frameworks

This was added previously in this commit.

2. Vendoring the dependency is fine, but the top level symbols will need to be prefixed in case someone's podspec also includes the same library. A quick glance says those would be an enum, a few string constants, and the class name

Thanks for the info; TIL: "Vendoring". Done.