iOS: Eliminate global in platformviews controller

[cbracken]

This is a minor refactoring that moves a global bool to a boolean ivar in FlutterPlatformViewsController. The purpose of this variable is simply to avoid the overhead of trying to create backdrop filters if we've ever failed to create one in the past.

Given that this class will only ever have the one instance created and held by per engine with the same duration, and that most apps only ever have one engine, the performance win will be identical for most apps. For the few add-to-app cases with multiple engines either at once or over the course of an app's lifetime, the costs associated with firing up an engine are already a far bigger hit than those being saved by this bool.

Also migrates from C++ style namespace { ... } to Obj-C style static functions. These are entirely equivalent as both restrict symbols to the current translation unit.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

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

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[hellohuanlin]

is the s prefix a common practice

[cbracken]

Will double-check but my recollection was that the style guide recommends a k prefix for constants, a g prefix for mutable globals, and an s prefix for statics. I believe we enforce naming on constants and mutable globals in our .clang-tidy rules. Will double check when I’m back at a computer.

[stuartmorgan-g]

I thought this too, but it looks like it's not in the style guide.

[cbracken]

I suppose the right thing to do here is to just make this an ivar. The whole point appears to be just to avoid the overhead of trying to create backdrop filters if we've ever failed to create one in the past.

This class will only ever have the one instance created and held by the engine for the duration of its life. Most apps only ever have one engine and the add-to-app cases with multiple engines either at once or over the course of an app's lifetime are already taking a far bigger hit than those being saved by this bool.

Mostly, this approach saves me scratching my head trying to remember whether the s prefix rule was real or imagined.

[stuartmorgan-g]

test-exempt: code refactor with no semantic change