fix: Adjust serialization to handle PEP-585 generic types

[vblagoje]

Why:

Improves type serialization, particularly focusing on better support for PEP 585 types (e.g., list[Document], including nested versions). This enhancement is crucial for enabling more accurate serialization of generics and nested types, which directly impacts the ability to match types like list[X] and List[X] in component connections after serialization.

• fixes Type serialization/deserialization failure with PEP-585 generics #7609

What:

• haystack/utils/type_serialization.py modification: Introduced better handling of PEP 585 types
• Test enhancements: Added multiple test cases in test/utils/test_type_serialization.py to verify the serialization and deserialization of PEP 585 types, including more complex nested types like list[list[int]].

How can it be used:

• Serialization of PEP 585 and nested types: Now users can serialize types like list[int] or more complex nested structures like list[list[str]] directly.

  # Example: Serializing a nested list type
  serialized_type = serialize_type(list[list[int]])

• Deserialization for advanced type checks: Following serialization, types can be accurately deserialized, maintaining their structure for further type checks or processing.

  # Example: Deserializing nested types back to their original form
  original_type = deserialize_type("list[list[int]]")

How did you test it:

• Added unit tests for both serialization and deserialization processes.
• Verified the serialization of PEP 585 types like list[int], including deeply nested types (e.g., list[list[list[int]]]).
• Ensured the deserialization process could accurately reconstruct the original types from their serialized form.
• These tests validate the changes by ensuring that both serialization and deserialization work as expected with PEP 585 types and their nested versions.

Notes for the reviewer:

• Impact on existing serialization: Reviewers should consider how these changes might interact with existing serialized types, particularly in edge cases not covered by the test scenarios.

[vblagoje]

Update: this fails for python 3.8 only, other versions work. Please hold the review @julian-risch

[vblagoje]

@julian-risch this should be ready now, please test in both 3.8 and 3.9 Python version and verify everything.

[coveralls]

Pull Request Test Coverage Report for Build 9069137605

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 15 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.06%) to 90.357%

---

Files with Coverage Reduction	New Missed Lines	%
components/fetchers/link_content.py	5	78.31%
utils/type_serialization.py	10	83.58%

Totals
Change from base Build 9030307905:	-0.06%
Covered Lines:	6531
Relevant Lines:	7228

---

💛 - Coveralls

[julian-risch]

LGTM! 👍 I also tried out the code example from the issue with python 3.8 and 3.10.
Only thing I wondered about is why we raise a ValueError instead of a SerializationError, which we define in haystack.core.errors. It doesn't affect this PR though and I would prefer keeping this PR as simple as small as possible.

[vblagoje]

LGTM! 👍 I also tried out the code example from the issue with python 3.8 and 3.10. Only thing I wondered about is why we raise a ValueError instead of a SerializationError, which we define in haystack.core.errors. It doesn't affect this PR though and I would prefer keeping this PR as simple as small as possible.

SerializationError was defined around the time when this type serialization code was written, lack of awareness most likely. Let's convert errors in a separate PR.