feat(serializer) : make buffer max capacity configurable

[LegendPei]

Purpose of the PR

• close Maybe the max buffer capacity should be customized #3046

This PR makes the max capacity of one serializer buffer configurable instead of always using the hardcoded default 128MB limit.

The default behavior remains unchanged, while users who need to serialize larger objects can tune the buffer limit through configuration. The new option is still bounded to avoid unbounded memory allocation.

Main Changes

• Trivial rework / code cleanup without any test coverage. (No Need)
• Already covered by existing tests, such as (please modify tests here).
• Need tests and can be verified as follows:
  • xxx

Does this PR potentially affect the following parts?

• Dependencies (add/update license info & regenerate_known_dependencies.sh)
• Modify configurations
• The public API
• Other affects (typed here)
• Nope

Documentation Status

• Doc - TODO
• Doc - Done
• Doc - No Need

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.25%. Comparing base (7f0a44a) to head (a08bdd6).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@              Coverage Diff              @@
##             master    #3049       +/-   ##
=============================================
+ Coverage     36.08%   93.25%   +57.17%     
+ Complexity      338       65      -273     
=============================================
  Files           803        9      -794     
  Lines         68227      267    -67960     
  Branches       8963       22     -8941     
=============================================
- Hits          24617      249    -24368     
+ Misses        40963        8    -40955     
+ Partials       2647       10     -2637     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[imbajin]

The implementation is close and the process-wide scope is the right fit for BytesBuffer. Please avoid last-opened-graph-wins behavior by making that process-wide semantic explicit and rejecting conflicting graph configs.

[VGalaxies]

Review summary

• Blocking: yes
• Summary: The PR leaves graph lock groups registered when the new serializer buffer capacity initialization fails, which can block a corrected retry in the same process.
• Evidence:
  • Static review
  • git diff --check origin/master...HEAD passed. mvn test -pl hugegraph-server/hugegraph-test -am -P unit-test -Dtest=BytesBufferTest failed before reaching the target tests because hugegraph-pd ran surefire with no tests

[imbajin]

Blocking: yes. Summary: The process-wide serializer buffer cap is still sourced from each graph config, so mixed custom/default graph configs can fail multi-graph startup. Evidence: static review of GraphManager local graph loading plus BytesBufferTest passed locally.

[imbajin]

‼️ Keep the process-wide cap from conflicting with default graph configs

Evidence: GraphManager loads every file under conf/graphs in one JVM, and each StandardHugeGraph calls BytesBuffer.initMaxBufferCapacity(config.get(...)). With this option stored as a graph option, the first graph that sets serializer.buffer_max_capacity=268435456 freezes the static cap, then any later graph that omits the option still passes the default 134217728 and fails with the new conflicting-value check.

Impact: enabling this option for one graph can prevent a normal multi-graph server from starting unrelated graphs, even though a process-wide setting should be shared by the process.

Requested fix: move the source to server-wide config, or treat an unset/default graph value as inheriting the already-initialized process value, and add a GraphManager/MultiGraphsTest case covering one custom graph plus one default graph.