chore(deps): use the released DataFusion 55.0.0 crates from crates.io

[andygrove]

Which issue does this PR close?

Part of #2369. Follow-up to #2301, which pinned DataFusion to the 55.0.0-rc3 tag.

Rationale for this change

DataFusion 55.0.0 is now published on crates.io, so the [patch.crates-io] table that redirected the DataFusion crates at a git tag has served its purpose. Depending on the released crates directly means cargo resolves from the registry instead of cloning apache/datafusion at build time, which is faster to build, works for downstream consumers of the Ballista crates, and is a prerequisite for publishing a Ballista 55.0.0 release.

What changes are included in this PR?

• Removed the [patch.crates-io] table from the root Cargo.toml
• Workspace DataFusion deps go back to plain crates.io requirements (datafusion = "55" and friends), with a comment explaining why they stay minor-version rather than exact patch pins
• Cargo.lock refreshed: every DataFusion crate moves from git+https://github.com/apache/datafusion.git?tag=55.0.0-rc3 to the registry at the same 55.0.0 version. No non-DataFusion dependency moved.
• The python/ workspace is untouched — it consumes published 54.0.0 crates and has no path dependency into this workspace. Bumping the Python bindings to 55.0.0 is tracked separately in Ballista 55.0.0 Release #2369.

Are these changes tested?

Existing CI covers this. Locally on macOS (aarch64):

• cargo check --workspace --all-targets --locked — clean
• cargo clippy --all-targets --workspace --all-features -- -D warnings — clean
• cargo check -p ballista-scheduler -p ballista-executor -p ballista-core -p ballista --no-default-features --locked — clean (the one unused_imports warning in ballista/client/src/extension.rs is pre-existing on main and unrelated to this change)
• cargo fmt --all -- --check, taplo toml fmt, and dev/update_datafusion_proto.py --check — all clean, so the vendored DataFusion protos need no resync

Are there any user-facing changes?

No API changes. Builds no longer need network access to github.com/apache/datafusion to resolve dependencies.

[avantgardnerio]

This makes sense for our "release branch" of Ballista 55 (doesn't literally need to be a branch), but is the plan to go back to tracking upstream main SHAs after we release?

[andygrove]

This makes sense for our "release branch" of Ballista 55 (doesn't literally need to be a branch), but is the plan to go back to tracking upstream main SHAs after we release?

Yes, exactly.