[camera] Expand CameraImage DTO with properties for lens aperture, exposure time and ISO.

[BeMacized]

(Resubmission of #4170)

This PR adds additional properties to the CameraImage DTO:

• lensAperture
• sensorExposureTime
• sensorSensitivity

Relevant issue:

• [camera] ISO, Shutter Speed, Aperture flutter#73250

This PR adds no breaking changes.

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]. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
• I signed the [CLA].
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I listed 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].
• I updated CHANGELOG.md to add a description of the change.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
• All existing and new tests are passing.

[mvanbeusekom]

I went through the code and noticed a potential null error which I wanted to double check.

[mvanbeusekom]

Quick check, is the null check on purpose? I can imagine that null indicates the value was not available for this particular capture result and you want to communicate this back to the Dart side.

Don't you now have the risk that you communicate a (invalid) previous value with the current image?

(this question also goes for the sensorExposureTime and sensorSensitivity values)

[BeMacized]

I think the way I had it in my head, is that in case you have some frames which do not supply these values, there's a very good chance the values will have been the same as the one from the frame(s) before it. Not sure if this is actually the case, but if you have a scenario where the camera implementation only reports back these values every X frames, there wouldn't be any issues like this.

I do agree that this might be confusing and potentially unwanted behavior. I'm not sure either whether my concerns actually have any ground, so I guess it depends on if caching these values is something we want to do or not.

[mvanbeusekom]

Since all frames are also send to Flutter, wouldn't it be better for the developer using the camera plugin to make this decision instead of we making it for him/her?

[BeMacized]

That would certainly be a simpler solution. I guess I'll just do that, if it turns out to give some trouble we can always add something like it back in later.

[BeMacized]

Looking at it now I just remembered why I implemented it this way in the first place:

These properties all have to be sent back in the handler given to imageStreamReader.setOnImageAvailableListener.
However, I ran into the problem here that I cannot actually access the CaptureResult which contains these values here. Instead, the capture result is only available in CameraCaptureCallback.

This is why I opted to cache these, as I don't really see any way of associating a specific Image from the stream with a specific CaptureResult. Associating the last known capture result sounded like the next best option.

We can still set the values back to null so results don't get merged, so I've removed the null checks.

[mvanbeusekom]

LGTM