Avoid object pool for message builder

[zhanglistar]

Fixes #476

Master Issue: #

Motivation

Modifications

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Documentation

• doc-required
  (Your PR needs to update docs and you will update later)

• doc-not-needed
  (Please explain why)

• doc
  (Your PR contains doc changes)

• doc-complete
  (Docs have been already added)

[BewareMyPower]

This test seems meaningless. Thread safety of concurrent shared_ptr creation is guaranteed by the standard library.

[zhanglistar]

Check whether it will crash.

[BewareMyPower]

I mean, this is guaranteed by the standard library and our unit tests should only focus on the SDK side.

This does not like a regression test as well because the object pool is not used to avoid concurrent build crash.

[BewareMyPower]

From LLM:

The test testMessageBuilderConcurrentBuild is not meaningful.

Each thread creates its own independent MessageBuilder instances — there is no shared mutable state between threads. The test is equivalent to running the existing sequential testMessageBuilder test in parallel 80,000 times, which doesn't validate any concurrency behavior specific to the code under test. std::make_shared (the replacement) is inherently thread-safe, and MessageBuilder methods operate on per-instance impl_ state with no global or shared data.

To be meaningful, the test would need to exercise a shared resource — for example, if it used a shared pool (the old ObjectPool) or shared metadata state. As written, it's just a stress test of the heap allocator, which isn't what the change is about.

From myself: testing concurrent creation of std::shared_ptr objects is not commonly seen. Such tests are meaningless, otherwise, we should also test concurrent creation of Producer, Consumer, etc.