refactor: Moves configuration creation for manifest to separate class

[fractalwrench]

Goal

This changeset is intended to reduce the complexity of the Client class, which is currently 757 SLOC. This is partially achieved by extracting the logic to populate Configuration from the AndroidManifest to a separate class.

Changeset

• Moves code which populates a configuration object from the AndroidManifest into a separate ConfigFactory class
• Update test imports to pass build

Tests

Ran unit tests, mazerunner

Review

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• Check the scope of the changeset - is everything in the diff required for the pull request?
• 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

For the pull request reviewer(s), this changeset has been reviewed for:

• 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

[coveralls]

Coverage decreased (-0.03%) to 74.906% when pulling ccaec5d on refactor-client-init into 0390356 on next.

[martin308]

Seems ok to me. I was curious if there are any implications (breaking changes) of changing some of the access modifiers here for external consumers

[martin308]

what's the default access modifier that's applied here? Does moving this have any external implications?

[fractalwrench]

The package-level modifier will be applied, so anything with the com.bugsnag.android namespace can access this. I don't believe this has any external implications as I'm not aware of any other notifiers which call this method.