Migrate low-level OpenSearch.Net serialization to System.Text.Json

[YiyuanMiao]

Is your feature request related to a problem?

Follow-up to the high-level serializer migration in #1002 (issue #388).

That PR migrates the high-level OpenSearch.Client serializer to System.Text.Json (opt-in). As part of it, a low-level STJ serializer (OpenSearch.Net.SystemTextJsonSerializer) and its supporting converters (ObjectConverter, DynamicDictionaryConverter real-number handling, the 9-field exception converter, ISO-8601 date converters, etc.) were also implemented and are covered by unit tests.

However, the low level is not actually migrated: ConnectionConfiguration still defaults to the mature Utf8Json engine (LowLevelRequestResponseSerializer). The STJ low-level converters exist and are correct, but are not on the default path — they only activate if a caller opts in. This was a deliberate scope decision to keep #1002 focused on the high level and avoid changing low-level behaviour (dynamic number formatting, sniff parsing, exception shapes) that the Utf8Json path serves today.

This is documented as a known limitation in dev-docs/system-text-json-migration.md (§5), and this issue tracks the remaining work so it isn't lost.

What solution would you like?

Complete the low-level migration:

• Make System.Text.Json the default (or explicitly selectable) engine for the low-level OpenSearch.Net client.
• Verify byte-for-byte parity with the Utf8Json path for the low-level-specific behaviours, in particular:
  • dynamic number formatting (e.g. preserving 3.0 rather than 3 for boxed
    doubles/decimals),
  • sniff response parsing,
  • exception serialization shape,
  • empty/blank response body handling.
• Exercise it under the dual-engine CI matrix already added in Migrate high-level serialization to System.Text.Json #1002.

What alternatives have you considered?

Keeping the low level permanently on Utf8Json. Rejected as a long-term option because the goal is to remove the vendored Utf8Json dependency entirely; the low level must move to STJ before that can happen.

Do you have any additional context?

Related: #388 (high-level migration), #1002 (high-level PR that landed the low-level STJ converters behind an opt-in).