feat(bridges): enable async query mode for all bridges with buffer workers

[thalesmg]

Fixes https://emqx.atlassian.net/browse/EMQX-9130

Since buffer workers always support async calls ("outer calls"), we should decouple those two call modes (inner and outer), and avoid exposing the inner call configuration to user to avoid complexity.

For bridges that currently only allow sync query modes, we should allow them to be configured with async. That means basically all bridge types except Kafka Producer.

Summary

🤖 Generated by Copilot at 066f73f

This pull request simplifies and unifies the schema definitions for various bridge resources by reusing the common resource_opts field from the emqx_resource_schema module and removing unused or redundant fields. It also makes the query_mode field more flexible and consistent across different resources, allowing both sync and async modes.

PR Checklist

Please convert it to a draft if any of the following conditions are not met. Reviewers may skip over until all the items are checked:

• Added tests for the changes
• Changed lines covered in coverage report
• Change log has been added to changes/{ce,ee}/(feat|perf|fix)-<PR-id>.en.md files
• For internal contributor: there is a jira ticket to track this change
• If there should be document changes, a PR to emqx-docs.git is sent, or a jira ticket is created to follow up
• Schema changes are backward compatible

Checklist for CI (.github/workflows) changes

• If changed package build workflow, pass this action (manual trigger)
• Change log has been added to changes/ dir for user-facing artifacts update

[coveralls]

Pull Request Test Coverage Report for Build 4599750578

• 14 of 14 (100.0%) changed or added relevant lines in 10 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.008%) to 81.048%

---

Totals
Change from base Build 4598063119:	-0.008%
Covered Lines:	25035
Relevant Lines:	30889

---

💛 - Coveralls

[thalesmg]

Noticed an issue with rule action statistics when using async actions. They always count as successes, because the rule engine doesn't wait for the reply. The bridge/connector returns just ok when async (it's just a cast), and that's immediately interpreted as a success.

Bridge (don't mind the 6 total; 2 messages were sent before restarting the rule stats):

Rule:

[thalesmg]

Noticed an issue with rule action statistics when using async actions. They always count as successes, because the rule engine doesn't wait for the reply. The bridge/connector returns just ok when async (it's just a cast), and that's immediately interpreted as a success.

Actually, this issue exists prior to the present changes. So we could merge this one as it is and create a follow up issue for fixing those metrics.

[zmstone]

Noticed an issue with rule action statistics when using async actions. They always count as successes, because the rule engine doesn't wait for the reply. The bridge/connector returns just ok when async (it's just a cast), and that's immediately interpreted as a success.

Actually, this issue exists prior to the present changes. So we could merge this one as it is and create a follow up issue for fixing those metrics.

yeah, it's a known "issue", and some argue it's not an issue.