feat: deprecate async_enabled replication argument removed server-side

[LijuanTang94]

Summary

Closes #2047

The asyncEnabled field was removed from the Weaviate server schema in v1.38 (weaviate/weaviate#11214). The client still accepted async_enabled and forwarded it on the write path, so the server silently dropped it — the user's intent was lost without any indication.

This PR adds a DeprecationWarning so the silent loss becomes visible, following the exact precedent the maintainers established for max_workers / alive_nodes_checking_frequency (Dep029) when those async_config fields were removed in v1.37.3.

Approach

I deliberately chose deprecate-and-warn over hard removal (the issue's step 3 offers both):

• Removing the public async_enabled kwarg outright would break any existing user code calling Configure.replication(async_enabled=...).
• The existing Dep029 handling keeps the kwarg + keeps forwarding (server drops it) + warns. This PR mirrors that pattern for consistency and zero breakage.

If the maintainers prefer to also drop the read-path field (_ReplicationConfig.async_enabled + the parser in config_methods.py, which now always reports a misleading False), I'm happy to extend the PR — I left it out to keep this change focused and non-breaking, and because removing a read attribute is a larger compatibility decision.

Changes

• weaviate/warnings.py — new Dep030 deprecation warning
• weaviate/collections/classes/config.py — Configure.replication and Reconfigure.replication emit the warning when async_enabled is passed; docstrings updated
• test/collection/test_config.py — tests that the warning fires when async_enabled is passed and stays silent otherwise (both factories)

Testing

pytest test/collection/test_config.py test/collection/test_config_update.py test/collection/test_config_methods.py
# 210 passed
ruff check / ruff format --check   # clean
flake8 (+ pydoclint, flake8-docstrings)  # clean

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[weaviate-git-bot]

To avoid any confusion in the future about your contribution to Weaviate, we work with a Contributor License Agreement. If you agree, you can simply add a comment to this PR that you agree with the CLA so that we can merge.

beep boop - the Weaviate bot 👋🤖

PS:
Are you already a member of the Weaviate Forum?

[LijuanTang94]

I have read the CLA and agree to the terms.

[LijuanTang94]

Hi team — just checking in on this PR. CLA is now signed and all checks are passing. Happy to make any changes if needed!

[LijuanTang94]

Rebased onto current main (was 70 commits behind) — no conflicts, and the diff is unchanged from the original.

Heads up on why this PR shows no test signal: the Main workflow has never actually run on it. Every run sits at action_required, i.e. it's waiting on first-time-contributor approval — only PR Security Lint and the Orca scans have executed. One click on Approve and run would surface the real Integration/Journey checks.

In the meantime I ran the unit suite locally against current main: 415 passed on main, 419 on this branch — the 4 extra are the new deprecation tests (2 cases × Configure.replication / Reconfigure.replication). ruff format --check is clean.

On the change itself — this is still live on server v1.38+: Configure.replication(async_enabled=...) is accepted by the client and silently dropped by the server, so the user's intent disappears with no signal. #2047 is still open and v4.23.0 shipped without a fix.

One decision I'd like a steer on, which I left out deliberately to keep this non-breaking: the read path (_ReplicationConfig.async_enabled and its parser in config_methods.py) now always reports False regardless of server state, which is arguably worse than not exposing it at all. Removing a read attribute is a compatibility call I didn't want to make unilaterally. Happy to extend this PR either way — just say which you'd prefer.

@jeroiraz — you filed #2047, so you're probably the right person for the read-path question.