Add json_deserialize parameter to ClientSession

[jtung1027]

What do these changes do?

Adds a json_deserialize parameter to ClientSession to configure JSON
deserialization at the session level, matching the existing json_serialize
parameter.

This allows users to configure a custom JSON deserializer (e.g., orjson.loads)
once at session creation, and all calls to ClientResponse.json() will use it by
default.

Additionally, fixed an inconsistency where json_serialize parameter defaulted to
json.dumps directly instead of using DEFAULT_JSON_ENCODER constant.

Are there changes in behavior for the user?

import aiohttp
import orjson

session = aiohttp.ClientSession(
    json_serialize=lambda obj: orjson.dumps(obj).decode(),
    json_deserialize=orjson.loads
)

async with session.get(url) as response:
    data = await response.json()  # Uses orjson.loads automatically

Is it a substantial burden for the maintainers to support this?

I don't think so.

Related issue number

1. PR feat: using orjson replace ujson #11439 - "feat: using orjson replace ujson" (Open, Aug 2025)

• Status: Open PR
• What it does: Attempts to replace ujson with orjson in documentation/examples
• Related to: Issue ujson library mentioned in the documentation is deprecated #10795
• Relation to your work: ❌ Different focus - They're changing documentation
  examples, you're adding a feature
• Conflict?: ❌ No conflict - Your PR doesn't touch documentation examples

2. PR Added support orjson for dumps of response #5578 - "Added support orjson for dumps of response" (Open, March 2021)

• Status: Open PR (stale - 4 years old!)
• What it does: Tried to make json_serialize accept bytes return values
• Relation to your work: ⚠️ Related but different - They wanted to support bytes
  from orjson, you're adding deserializer config
• Conflict?: ❌ No conflict - Different scope (they modified payload.py, you
  modified client.py/client_reqrep.py)

3. Issue Client should accept a json_serialize function which returns bytes #4482 - "Client should accept json_serialize function which returns bytes"
   (Closed, Jan 2020)

• Status: Closed
• What it was: Request for orjson support (which returns bytes)
• Resolution: Users now use workaround: lambda x: orjson.dumps(x).decode()
• Relation to your work: ✅ Your PR continues this conversation - You're making
  orjson usage more ergonomic
• Conflict?: ❌ No conflict - Issue is closed, and your PR doesn't change this
  aspect

4. Issue ujson library mentioned in the documentation is deprecated #10795 - "ujson library mentioned in the documentation is deprecated"
   (Open, April 2025)

• Status: Open
• What it is: Request to update docs to recommend orjson instead of ujson
• Relation to your work: ✅ HIGHLY RELEVANT - Your PR makes it easier to use orjson!
• Conflict?: ❌ No conflict - Actually complements the discussion

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the CHANGES/ folder

  • name it <issue_or_pr_num>.<type>.rst (e.g. 588.bugfix.rst)

  • if you don't have an issue number, change it to the pull request
    number after creating the PR

    • .bugfix: A bug fix for something the maintainers deemed an
      improper undesired behavior that got corrected to match
      pre-agreed expectations.
    • .feature: A new behavior, public APIs. That sort of stuff.
    • .deprecation: A declaration of future API removals and breaking
      changes in behavior.
    • .breaking: When something public is removed in a breaking way.
      Could be deprecated in an earlier release.
    • .doc: Notable updates to the documentation structure or build
      process.
    • .packaging: Notes for downstreams about unobvious side effects
      and tooling. Changes in the test invocation considerations and
      runtime assumptions.
    • .contrib: Stuff that affects the contributor experience. e.g.
      Running tests, building the docs, setting up the development
      environment.
    • .misc: Changes that are hard to assign to any of the above
      categories.

  • Make sure to use full sentences with correct case and punctuation,
    for example:

    Fixed issue with non-ascii contents in doctest text files
    -- by :user:`contributor-gh-handle`.

    Use the past tense or the present tense a non-imperative mood,
    referring to what's changed compared to the last released version
    of this project.

[codspeed-hq]

CodSpeed Performance Report

Merging #11741 will not alter performance

_{Comparing jtung1027:add-session-json-deserialize-parameter (eac0fef) with master (056d929)}

Summary

✅ 59 untouched

[Dreamsorcerer]

I think we maybe want to add the bytes version first (#10795 (comment)), and then see if that has any effect on this parameter.

We'd also need the reference docs updated to include the new parameter.