feat(c++): add sanitizer configuration in bazel build and CI

[BaldDemian]

Why?

Close #1203

What does this PR do?

• Add ASan and UBSan integration in .bazelrc.

• I noticed that directly running bazel test $(bazel query //cpp/...) triggers compilation errors because the --config=x86_64 flag is not provided. In the new CI Python script run_ci.py, the cpp.py task invoked by it indeed contains a check for this flag:
  

  fory/ci/tasks/cpp.py

  Lines 40 to 41 in af6e8b2

  	if common.get_os_machine() == "x86_64":
  	test_command += " --config=x86_64"

  
  The run_ci.sh script does not contain this check. Although this script appears to no longer be used, I still added the corresponding flag check there.
  Similarly, I also added documentation about this flag in AGENTS.md.

• In ci.yml, I added a new job to enable tests with sanitizers in CI. Currently, this job only runs on ubuntu-latest.

Related issues

#1203

Benchmark

I believe this feature only introduces extra burden during testing.

[BaldDemian]

Results

Local testing:

• ASan:
  Run bazel test --cache_test_results=no --config=x86_64 --config=asan $(bazel query //...)
  All tests passed, and no memory access errors were detected. Logs are available in this file: asan_report.txt
• UBSan:
  Run bazel test --cache_test_results=no --config=x86_64 --config=ubsan $(bazel query //...)
  Normally, when integrating UBSan, it is necessary to add the following line in .bazelrc: build:ubsan --copt=-fsanitize=undefined.
  However, with gcc, running the above bazel test command leads to a compilation failure.
  See this file for details: ubsan_compiling_error.txt.
  This compilation failure appears to be caused by a known and unresolved bug in gcc. See this discussion for reference: https://stackoverflow.com/questions/79775145/adding-fsanitize-undefined-in-gcc-makes-reflect-cpp-header-not-compile-anymore
  undefined is an aggregate sanitizer flag, and the list of its sub-options can be found here: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize_003dundefined
  After some investigation, it seems that enabling the sub-options null, nonnull-attribute, and returns-nonnull-attribute will all trigger the compilation failure. The current workaround is to manually expand the sub-options included in undefined and exclude the three options above. With this configuration, the compilation error no longer occurs.
  Test results: several misaligned address runtime errors were indeed detected.
  However, due to the default behavior of UBSan(continuing execution even when errors are reported), the final result still shows that all tests passed. From the log file
  ubsan_report.txt
  (search for runtime error), the error appears to originate mainly from buffer.h. I will further investigate the code to check whether this is indeed a bug.

CI testing:
Newly added jobs and the existing ones all passed in my local fork: BaldDemian@95334b2

[BaldDemian]

This sole failed CI job seems to be a network issue 🤔. It passed in my local fork, so simply rerunning it may solve the problem.

[ayush00git]

This sole failed CI job seems to be a network issue 🤔. It passed in my local fork, so simply rerunning it may solve the problem.

pushing an empty commit would re-run the ci, try git commit --allow-empty -m "ci" and then push it

[BaldDemian]

After some investigation, I can confirm that the misaligned address access UB mentioned above is caused by the way buffer.h creates types that require alignment using reinterpret_cast directly, e.g.

fory/cpp/fory/util/buffer.h

Lines 885 to 892 in ed586af

	FORY_ALWAYS_INLINE int16_t read_int16(Error &error) {
	if (FORY_PREDICT_FALSE(!ensure_readable(2, error))) {
	return 0;
	}
	int16_t value = reinterpret_cast<const int16_t *>(data_ + reader_index_)[0];
	reader_index_ += 2;
	return value;
	}

In this method, int16 requires 2 byte alignment, but reinterpret_cast cannot guarantee or check this requirement.
I am preparing a PR to fix this issue.