Add batch read-write methods for GPIO

[HumJ0218]

for #2147

The original public void Write(ReadOnlySpan<PinValuePair> pinValuePairs) and public void Read(Span<PinValuePair> pinValuePairs) in GpioController were moved to GpioDriver, and were made overrideable to support a more efficient batch read-write method implementation in specific GPIO driver classes.

Microsoft Reviewers: Open in CodeFlow

[pgrawehr]

Looks good from an implementation point of view, but this has broken the test suite. Could get a bit nasty to fix, because Span<T> cannot be part of a method that is mocked.

[pgrawehr]

Looks good to me. We'll discuss it in the next team meeting.

[Ellerbach]

Looks good. Once merge, I can definitely get some perf improvements for the FT family as well.

[pgrawehr]

Helix tests are still failing.

The baseline comparison tests can be ignored for now, that's easy to clarify and fix.

[HumJ0218]

I'm a bit puzzled about this compilation error.

Why would the "protected internal" of the base class be considered as "public" in the compilation process, causing the compilation error CP0019?

[pgrawehr]

@HumJ0218 Can you show exactly what change causes this? Also, are you sure you meant CP0019? I cannot find this error code. What exactly is reported?

[HumJ0218]

@HumJ0218 Can you show exactly what change causes this? Also, are you sure you meant CP0019? I cannot find this error code. What exactly is reported?

https://dev.azure.com/dotnet/IoT/_build/results?buildId=99483&view=logs&j=fa59fe4e-195c-56fa-189b-58fd241f10dd&t=afa1ce5e-d2bc-56f3-ad78-7883f25a3e3a&l=874

[pgrawehr]

Oh, that. That's just our compatibility check. It verifies that the build doesn't break backwards compatibility against the previous release. Since changing a method from public to protected is a breaking change, it complains. In this case, I think we're fine with accepting that breaking change and you can update the configuration accordingly. Run the following command to automatically update the suppressions for this warning:

build -pack /p:GenerateCompatibilitySuppressionFile=true

It should update the file src\Iot.Device.Bindings\CompatibilitySuppressions.xml.

[Ellerbach]

[Triage] @HumJ0218 is the use case still valid? If yes, can you please address the conflict and adjust the different elements? If no, we will close the PR which can anyway always been reopened.