Add SwiftLinter

[pharms-eth]

add Swift Linter in a Xcodeproj file to start cleaning up each rule
disabled all default rules to re-add one by one

other changes in here from Async work, PR will simplify when other PR is merged

[mloit]

Couple of things. first we already have a .swiftlint.yml in the root of the repo, so if we're adding/changing rules it should be done there. Secondly you appear to have several updates to your swiftlint in the form of other PR's that look to be just commits against this PR. Since they are all relative to this one, I suggest combining them to this one, as this one is still 'in progress' until it is merged. You can keep making new commits against this one, and not need to open a new PR for every change.

[pharms-eth]

the .swiftlint.yml file I currently have in here is for in place cleanup. When I open this PR (no longer draft) I will remove my working copy and update the project one

[mloit]

I see, okay. That's fine then.

Thank you for removing the 3 redundant PR's from yesterday, but 2 more popped up today. Please update your process, so you are not generating new PR's on what is really just work against PR. The PR will automatically track any commits made to the branch you created it from ([your-repo]/SwiftLint). If you make a branch from that to try something, all you need to do is merge it back into [your-repo]/SwiftLint and push, and the PR will track those changes.

[yaroslavyaroslav]

Please close the pr and merge changes made here into #515

[yaroslavyaroslav]

Copy paste recent comment of @mloit here:

This PR may fix those. They are separate in the sense that this contains lint fixes across the entire repo, where that PR is focused on switching from PromiseKit to Async/Await. He has branched this PR from that one (actually this PR is branched from #524, which was branched from #515), so all the changes there are included here. I've refrained from reviewing this one until that one has been merged as it's impossible to otherwise separate the changes from which PR they are being made in.

In my opinion I think it best to keep them separate, and comment on any lint issues in the changes of that PR there. Then after that one is merged, this one (and the others he has) should clean up a bit. Though as they are still branched from each other it is impossible to separate the unique changes in this one, vs those made in #524. Personally I don't like this form of PR as we end up reviewing the same changes over and over again, and makes it very difficult to focus on the changes that the PR is actually supposed to be focused on.