STITCH-1597 Run swiftlint for all build targets

[adamchel]

Drive-Bys

• Fixed Podfile so tests run out of the box without the “image not found” error.
• Added missing test and build schemes, tried to fix the dependency graph and other various issues with the build system

Main Changes This PR adds a linter build phase to every single XCode project in the Stitch.xcworkspace, and resolves all linter warnings and errors except where noted in this PR. I added the following exceptions

• In each test file or admin client file, I added any of the following rule exceptions that were required to get the linter to not show any warnings. I did this because I don’t think it’s worth refactoring tests to meet length/complexity requirements. I never add these exceptions in the actual SDK code that users will use, except where otherwise stated in this PR.
  • cyclomatic_complexity
  • file_length
  • force_cast
  • force_try
  • function_body_length
  • nesting
  • type_body_length
  • type_name for long unit test class names
• In protocol declarations, I added exceptions for line_length where required for jazzy to properly interpret long function declarations (see https://github.com/realm/jazzy/issues/896)
• In files for our Mock Utils, I added exceptions for the following since I feel like mocking falls under tests and we shouldn’t spend too much time refactoring the mocking:
  • file_length
  • force_cast
  • large_tuple
• In the deprecated AWS S3 service, I added exceptions for parameter_count since fixing this would be a breaking change for an API that’s already deprecated. The new AWS service uses the more reasonable approach of a request object so this issue will go away whenever we phase out the old AWS services (maybe v5)
• In the root directory for various services, I added a .swiftlint.yml file defining specific exceptions for the rule that identifiers must be 4-40 characters. These only included the following identifiers:
  • id (used in many places)
  • key
  • jwt
  • to (used in SES, Twilio and FCM service)
  • db

The linter build phases treat linter warnings as build warnings, and linter errors as build errors. Linter errors will prevent building from completing and will thus be caught by evergreen, but linter warnings will not currently be caught by Evergreen.

I will open a ticket that adds an evergreen task that runs the linter and verifies there are no linter warnings. This should be straightforward (just running swiftlint in each of the root project directories, checking that there is no stdout output)

This PR also leaves five linter warnings unresolved, all in StitchCoreSDK. Fixing these warnings would involve refactoring CoreStitchAuth to move some logic out into extensions or helper files, and uncommenting some code to make use of a resolved SWIFT ticket. I’ll open a ticket to fix these since we decided refactoring non-trivial lint errors was out scope.

Lastly, I’ll open a ticket for Jason to merge master into the sync branch since there will likely be conflicts and dealing with them may take a non-trivial amount of time.