[camerax] Make fixes required to swap camera_android_camerax for camera_android

[camsim99]

Makes changes needed to land #6629. Specifically:

• Fixes timing issue with stopVideoRecording such that the Future it returns will only complete when CameraX reports that the recording is finalized (via listening for the finalized video recording event)
• Modifies startVideoCapturing such that the Future it returns will only complete when CameraX reports that video capturing has started (via listening for the started video recording event)
• Adds empty implementation and TODO for implementing setDescriptionWhileRecording

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 relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• 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 this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

[reidbaker]

I think we can make this test a bit better by comparing on both sides of the stopRecording call.

Suggested change

	sleep(const Duration(seconds: 2));
	final XFile file = await controller.stopVideoRecording();
	final int recordingTime =
	DateTime.now().millisecondsSinceEpoch - recordingStart;
	// Test should pass with this at any non zero value.
	sleep(const Duration(seconds: 2));
	final int preStopTime =
	DateTime.now().millisecondsSinceEpoch - recordingStart;
	final XFile file = await controller.stopVideoRecording();
	final int postStopTime =
	DateTime.now().millisecondsSinceEpoch - recordingStart;
	....
	expect(duration, greaterThan(preStopTime));
	expect(duration, lessThan(postStopTime));

Note:
We should be using a package like https://pub.dev/packages/system_clock because DateTime.now is vulnerable to the clock changing while the test is running but that feels out of scope.

[camsim99]

The preStopTime check didn't quite work I assume because stopping video recording takes so long but I kept the naming of postStopTime for clarity

[reidbaker]

It shouldn't matter how long stopping recording takes.

The timeline:
start recording
record start time
delay
record prestop time
trigger stop

The comparison for prestop does not depend on the length of time it takes to stop recording.
At minimum the recording should be longer than the pause duration. What is the value of duration when the test fails?

[camsim99]

Or maybe the start recording is slow I mean? The duration was 1448 ms (which is also below the 2000 ms of recording), prestop was 2002 ms.

[camsim99]

I suppose we could also fix this by listening for the VideoRecordEvent.Start event to return. Let me give it a go!

[camsim99]

@reidbaker Ok so I added the fix but it didn't quite work still :/ the duration increased but guessing there still some lag time in starting the video. Still left it in though as it is a better approximation.

[camsim99]

Going to land this as-is since I've done all I can to remedy this issue. If we feel like we need this fixed, I can file a bug and escalate to CameraX.

[camsim99]

Filed flutter/flutter#148138 for this.

[reidbaker]

Does this mean we have a feature we know will silently stop working when we modify the default to camerax?

[camsim99]

It does mean that :/ but the fact that it will be a breaking change can mitigate that fact; it will be noted in the README here but I can also add it to the camera/camera CHANGELOG and camera/camera README.

@stuartmorgan any thoughts on this? I realized recently that this was not implemented for camera_android_camerax.

[stuartmorgan]

I would definitely note the loss of functionality in the CHANGELOG for the camera breaking change.

This is a pretty new feature IIRC, and I would expect relatively niche, so losing it in a breaking change doesn't seem like a major issue. People will always have the possibility of using camera_android (or a fork of it, if/when we stop maintaining it) if they need it.