Add unified tuple validator that can handle "variadic" tuples via PEP-646

[dmontagu]

This adds new capabilities for tuple validation that are necessary to accommodate variadic generic tuples in pydantic.

I don't think this will fully pave the way for validating callables with a variadic signature, but I think the tuples case is more important anyway for typical pydantic usage. And if/when we do implement it for callables, it will probably look similar.

I believe we can replace the 'tuple-positional' and 'tuple-variable' schemas with the 'tuple' schema introduced in this PR, but I'm not yet sure about any potential performance consequences that might have.

(I'm also not sure it even works properly yet — I need to add more tests, and check if all pydantic tests pass if I replace the use of 'tuple-positional' and 'tuple-variable' in pydantic.)

This is closely related to pydantic/pydantic#5804 but does not close it quite yet — this needs additional work in pydantic, and possibly some implementation for other non-tuple types before that issue could/should be closed.

[codecov]

Codecov Report

Merging #865 (2a65bb2) into main (a1b934f) will decrease coverage by 0.18%.
The diff coverage is 91.80%.

❗ Current head 2a65bb2 differs from pull request most recent head 1beadd8. Consider uploading reports for the commit 1beadd8 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #865      +/-   ##
==========================================
- Coverage   89.88%   89.71%   -0.18%     
==========================================
  Files         106      106              
  Lines       16436    16386      -50     
  Branches       35       36       +1     
==========================================
- Hits        14773    14700      -73     
- Misses       1656     1679      +23     
  Partials        7        7              

Files	Coverage Δ
python/pydantic_core/core_schema.py	94.75% <100.00%> (-0.02%)	⬇️
src/validators/mod.rs	95.07% <100.00%> (-0.32%)	⬇️
src/serializers/shared.rs	80.33% <0.00%> (ø)
src/serializers/type_serializers/tuple.rs	96.17% <96.10%> (+2.92%)	⬆️
src/validators/union.rs	89.11% <0.00%> (+1.50%)	⬆️
src/validators/tuple.rs	94.02% <92.85%> (+0.65%)	⬆️

... and 37 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a1b934f...1beadd8. Read the comment docs.

[codspeed-hq]

CodSpeed Performance Report

Merging #865 will improve performances by 15.27%

_{Comparing variadic-tuple (1beadd8) with main (a1b934f)}

Summary

⚡ 1 improvements
✅ 139 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	variadic-tuple	Change
⚡	test_core_future	55 µs	47.7 µs	+15.27%

[adriangb]

I believe we can replace the 'tuple-positional' and 'tuple-variable' schemas with the 'tuple' schema introduced in this PR, but I'm not yet sure about any potential performance consequences that might have.

Should we add some benchmarks to check?

We never ended up using the "extra" items validation in tuples and I recall it being a pain last time I touched this code. How does that intersect wit this PR? Would removing it help?

[adriangb]

I won't say that the implementation looks straightforward but from what I remember of the other two it's reasonably comparable in complexity / LOC given that it absorbs both of them.

[davidhewitt]

Overall functionality looks good, I'd like to see some tidying up in the implementation.

In particular given the switch of all tests to use the new validator I'd like to see the old tuple validators removed and new BuildValidator structures which can remap the old schemas onto this new implementation.

[dmontagu]

Note: this will break the pydantic integration tests if merged until pydantic/pydantic#7198 is also subsequently merged.

[dmontagu]

I ran the benchmarking locally — the old tuple-positional stuff is about 3-6% slower with this change, but the tuple-variable stuff is 25-40% slower. I think it makes sense to see if we can improve that at all, at least the variable, before merging this.