Fix MongoDB ObjectSerializer registration to allow user type deserialization

[Copilot]

When using MongoDB persistence with user-defined data classes, users encounter a BsonSerializationException:

Type WorkflowCore.Sample04.MyDataClass is not configured as a type that is allowed to be deserialized for this instance of ObjectSerializer.

This occurs when enabling MongoDB persistence in Sample04:

services.AddWorkflow(x => x.UseMongoDB(@"mongodb://localhost:27017", "workflow"));

The issue stems from the DataObjectSerializer.Deserialize method using BsonSerializer.Deserialize(context.Reader, typeof(object)), which relies on MongoDB's global ObjectSerializer. By default, this serializer has security restrictions that prevent deserialization of user types.

This fix adds ObjectSerializer registration in the static constructor of MongoPersistenceProvider that allows:

• All default allowed types (primitive types, etc.)
• WorkflowCore types (for backward compatibility)
• All user-defined types while blocking System.* and Microsoft.* types for security

Enhanced for Real-World Usage:
The solution now supports real-world scenarios where developers use their own application namespaces for workflow data classes, such as:

• MyApp.Models.CustomerData
• SomeCompany.Workflows.Data.OrderData
• WorkflowCore.Sample04.MyDataClass (existing samples)

Security:
Maintains proper security by preventing deserialization of potentially dangerous system and framework types while allowing legitimate user data classes.

Testing:
Created and verified comprehensive tests that reproduce the original issue and confirm the fix works for various user type scenarios including real-world namespaces beyond WorkflowCore.

Fixes #1372.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[danielgerlag]

@copilot this is only going to work because of the namespace of the samples, that will not be true in a real world use case.

[Copilot]

@copilot this is only going to work because of the namespace of the samples, that will not be true in a real world use case.

You're absolutely right. I've enhanced the fix to support real-world user types beyond just WorkflowCore namespaces.

The updated ObjectSerializer registration now allows:

• Default allowed types (primitives, collections, etc.)
• WorkflowCore types (backward compatibility)
• All user types while blocking System/Microsoft types for security

This works for user namespaces like MyApp.Models.CustomerData or SomeCompany.Workflows.Data.OrderData. Tested successfully with comprehensive scenarios.

Fixed in commit 70e02bb