Allow unions of unions

[dsnam]

The checks on union choices do not allow for unions that contain other unions, even if those unions when flattened would still be all-primitive or all-model. For example in our project we have a set of response codes in an XML schema we are modeling using this library:

type PermissionErrors = Literal[-4, -5]
type ServerErrors = Literal[-10, -11]
type CommonCodes = PermissionErrors | ServerErrors
type Request1ErrorCodes = Literal[-1, -2]
type Request1SuccessCodes = Literal[10, 11]
type Request1Codes = CommonCodes | Request1ErrorCodes | Request1SuccessCodes

Base Pydantic handles a field of type Request1Codes fine, but pydantic-xml does not:

================================================= short test summary info =================================================
FAILED tests/test_unions.py::test_nested_primitive_union - pydantic_xml.errors.ModelFieldError: Model.element1 field type error: union must be of primitive or model type
FAILED tests/test_unions.py::test_nested_model_union - pydantic_xml.errors.ModelFieldError: TopLevelModel.top_element1 field type error: union must be of primitive or model ...
============================================== 2 failed, 18 passed in 0.41s ===============================================

I modifed union.py to flatten union choices down when they consist of other unions so that the check on whether the union is not a mix of primitives and models still happens, but it no longer rejects a union that contains another union.

For anyone else running into this, a workaround is just to manually flatten your unions, ie the example above becomes:

type PermissionErrors = Literal[-4, -5]
type ServerErrors = Literal[-10, -11]
type Request1ErrorCodes = Literal[-1, -2]
type Request1SuccessCodes = Literal[10, 11]
type Request1Codes = PermissionErrors | ServerErrors | Request1ErrorCodes | Request1SuccessCodes

but this has the downside of requiring duplication (for us CommonCodes is quite a bit larger and reused extensively) and not exactly matching your schema, plus not everyone has control over the types they are modeling.

[dsnam]

I was not the biggest fan of having to call this both in the module level from_core_schema and in both of the classmethods here, but I did not want to mutate schema. If it's ok to do that I could make this a bit less redundant. Alternatively I could pass in the flattened schemas as an extra argument.

[dapper91]

I think it is ok to mutate the schema in the outer from_core_schema as far as we keep it correct. But it is better to deepcopy it before since we don't know how it could affect pydantic itself.

[dsnam]

Sounds good, I have reworked it to mutate a deepcopy of the schema and pass that flattened schema along to the serializers

[dapper91]

it seems like this procedure must be recursive since the union nesting level can be not only 2, but 3, 4 ...

[dsnam]

I believe this is covered with no recursion because when a union choice is found its choices are added to the same list the while loop is using, so it continues until everything is flattened, but I did discover I had missed a case where a choice is a definition-ref, is that what you meant? I updated a test case to include an additional level and added looking up definition-refs. Let me know if you think I'm missing something else here.