Make JsonData Immutable

[annelo-msft]

Modifications to JsonData by @jsquire.

Addresses #30717

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

Azure.Core.Experimental

[danielmarbach]

How about?

Suggested change

	return new BinaryData(memoryStream.ToArray());
	return new BinaryData(memoryStream.GetBuffer().AsMemory(0, (int)stream.Position));

[JoshLove-msft]

This is how the BinaryData FromStream method constructs the instance after copying into a separate MemoryStream - https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/core/System.Memory.Data/src/BinaryData.cs#L179

I think the reason we didn't type sniff for MemoryStream and attempt to extract the ArraySegment is that we wanted the semantics to be consistent across different streams.

[annelo-msft]

@jsquire, do you know why we implement IDynamicMetaObjectProvider instead of inheriting from DynamicObject?

[jsquire]

@jsquire, do you know why we implement IDynamicMetaObjectProvider instead of inheriting from DynamicObject?

I do not. @ellismg would probably have insight.

[ellismg]

I do not. @ellismg would probably have insight.

I can't recall the exact reason, but if I had to hazard a guess, it would be that we didn't want to inherit all of the public methods from DynamicObject on to our public surface area and into intellisense. Suspect that's also why we decided to explicitly implement the interface.

[annelo-msft]

I can't recall the exact reason, but if I had to hazard a guess, it would be that we didn't want to inherit all of the public methods from DynamicObject on to our public surface area and into intellisense. Suspect that's also why we decided to explicitly implement the interface.

We're investigating making the JsonData API fully internal, so I revisited this question.

It looks like all the TryXx methods on DynamicObject only get called after an attempt to access the dynamic property/conversion/method etc on the underlying typed instance fails and throws an exception, which would degrade performance. So, I think we will still want to implement IDynamicMetaObjectProvider even if the API is internal.

There's also the following comment in the DynamicObject reference docs, supporting this hypothesis:

if you need to manage DLR fast dynamic dispatch caching, create your own implementation of the IDynamicMetaObjectProvider interface.

See: https://learn.microsoft.com/en-us/dotnet/api/system.dynamic.dynamicobject?view=net-7.0#remarks

[annelo-msft]

Closing in favor of #31769