Fix: Handle JsonSerializerOptions without TypeInfoResolver

[GeorgiPopovIT]

Added GetSerializerOptions() helper method in AIFunctionMcpServerTool and ensure JsonSerializerOptions have proper TypeInfoResolver configuration.

Executed tests and they passed.

Fixes #1150

[stephentoub]

@eiriktsarpalis, is it desirable to mutate the externally-provided JsonSerializerOptions like this?

And is this thread-safe? What would happen if this JSO were passed to two McpServerTool.Create calls concurrently?

[eiriktsarpalis]

Νο. And even if it was, it would fail assuming the passed instance were read-only.

[stephentoub]

@eiriktsarpalis, thanks. What is the right answer for #1150? We should support someone passing in new JsonSerializerOptions() { ... }.

[eiriktsarpalis]

It's using the copy constructor like the PR was doing originally. That does have the side-effect of creating a new JSO and repopulating caches every time the method is invoked.

[stephentoub]

How does JsonSerializer.Serialize(..., jso) avoid that? Or does it also create a new instance on each call?

[eiriktsarpalis]

Reading #1150 more closely, I believe the user expects that we replicate the semantics of the non-AOT friendly JsonSerializer.Serialize(JsonSerializerOptions) methods which do silently mutate the JsonSerializerOptions. We can approximate that behavior while preserving AOT compatibility as follows:

if (options.TypeInfoResolver is null)
{
    Debug.Assert(!options.IsReadOnly, "If no resolver is present then the options must still be editable");
    options.TypeInfoResolver = McpJsonUtilities.DefaultOptions.TypeInfoResolver;
    options.MakeReadOnly();
}

[eiriktsarpalis]

How does JsonSerializer.Serialize(..., jso) avoid that? Or does it also create a new instance on each call?

Just saw this but I think my last response should asnwer your question.

[stephentoub]

Thanks for the efforts here. Replaced by #1221.