[ci] Allow warnings during podspec lint check

[jmagman]

xcode-analyze CI command handles catching code-level warnings. Allow warnings during pod lib lint command since it's redundant and we have fewer knobs to turn there.

See flutter/flutter#170437 (comment)

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[stuartmorgan-g]

Wouldn't this also allow warnings that are podspec-level warnings rather than code-level warnings?

In pratice, if things don't fail CI, people almost never look at the output, so "allow warnings" is, from the standpoint of preventing landing mistakes, essentially equivalent to "don't report warnings at all. I don't know offhand what the scope of things that cocoadpods itself reports as errors vs warnings, so I don't know what non-code-analysis coverage we would lose here.

Do we think this is better than --quick? I would guess it's likely worse, and is definitely going to be more expensive.