feat(sensors_plus): Configurable sample rate

[tlserver]

Description

• Support changing samplingPeriod for different sensors.

  void main() {
    final oldGetterStillWork = accelerometerEvents; // default to SensorInterval.normalInterval = 200ms
    final newEntryPoint = accelerometerEventStream(samplingPeriod: SensorInterval.gameInterval);
    final customInterval= accelerometerEventStream(samplingPeriod: Duration(seconds: 6));
  }

• Introduce SensorInterval class to provide 4 androids interval constants.

  normalInterval = Duration(milliseconds: 200);
  uiInterval = Duration(milliseconds: 66, microseconds: 667);
  gameInterval = Duration(milliseconds: 20);
  fastestInterval = Duration.zero;

• Updated example
  

• Rewrited ios platform-specific code in swift

Attention needed:

• This new feature support both android and ios, but not web (need help).
• The document may need to update and tell user that specific permission is needed for very small sensor interval ( <20ms ? ).

Implementation details:
xxxEventStream always return the same stream. If the method is called with different samplingPeriod later, the stream is changed to the new value. All previous listeners are affected. Note that this is same behaviour as ios but different than android.

In android, each registered handler has its own sampling period, and the system use the fastest sampling period value. For example, handler A with samplingPeriod=250ms and handler B with samplePeriod = 100ms are registered, the system try to update sensor every 100ms. But if handler B is unregistered later, system try to update sensor every 250ms then.

Known issue:
In previous version, FPPMagnetometerStreamHandlerPlus use deviceMotion instead of magnetometer to allow iOS present calibration interaction. So, in iOS, userAccelerometerEventStream and magnetometerEventStream share the same sampling period. In android, they have their own sampling period. See also #2250.

Related Issues

Resolve #439
Resolve #1318
Resolve #1381

#1280

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I titled the PR using Conventional Commits.
• I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
• All existing and new tests are passing.
• The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
• No, this is not a breaking change.

[vbuberen]

Thank you for this valuable contribution. I will get to check your PRs by the end of this week.

In the meantime, could you please fix formatting issues, so CI checks pass?

[vbuberen]

Other issues related to this topic:

#439
#1280
#1381

[vbuberen]

Looks mostly fine to me except a few minor moments.
Will do some additional testing tomorrow on Android as results on real devices seemed a bit odd during testing today. Afterwards would be good to merge and release.

P.S. Sorry for getting back that late.

[vbuberen]

Looks good.

As I mentioned in the previous comment on iOS everything works Ok, while on Android depending on version and device delays more than 200 ms don't always work and data is provided faster anyway.
However, it seems Ok based on the description of samplingPeriodUs parameter: https://developer.android.com/reference/android/hardware/SensorManager.html#registerListener(android.hardware.SensorEventListener,%20android.hardware.Sensor,%20int)