Add apiKey as a mutable property of BugsnagEvent

[robinmacharg]

Goal

Add an apiKey property to BugsnagEvent (nee BugsnagCrashReport). The behaviour is:

• Library consumers should be able to change the API key of event from OnError callbacks
• The property defaults to the value from BugsnagConfiguration.apiKey.
• Changing this value should change the API key used in the payload body and header but not the global Configuration value.

Design

A simple @property with custom getter/setter logic and validation. The BugsnagConfiguration.isValidApiKey method was promoted to class-level since it's now used in two places.

Failing validation logs the failure but doesn't throw an error. The thinking is that there will always be a fallback valid (32 digit hex string) apiKey and so event capture is the priority.

Changeset

Just BugsnagEvent.m/h and associated unit tests.

Tests

Tested that:

• The value retrieved the Configuration value when unset.
• A new value could be set in the event callback and this did not change the global value.
• The validation failure behaviour is correct.

Did not add any testing that the overridden apiKey value is correctly being sent to the backend via HTTP headers although this was observed in informal testing. A solution to this involving swizzling the ApiClient class was examined but deemed unnecessarily complex.

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

[fractalwrench]

I left a couple of minor comments but otherwise this change LGTM. Happy for it to be merged once the tests are passing and comments resolved 👍