Add udp2, an experimental IPC layer implementation

[zhangyue1818]

Fixes #ISSUE_Number

What does this PR do?

Type of Change

• Bug fix (non-breaking change)
• New feature (non-breaking change)
• Breaking change (fix or feature with breaking changes)
• Documentation update

Breaking Changes

Test Plan

• Unit tests added/updated
• Integration tests added/updated
• Passed make installcheck
• Passed make -C src/test installcheck-cbdb-parallel

Impact

Performance:

User-facing changes:

Dependencies:

Checklist

• Followed contribution guide
• Added/updated documentation
• Reviewed code for security implications
• Requested review from cloudberry committers

Additional Context

CI Skip Instructions

---

[leborchuk]

Awesome! Could you please share some information about the architecture of the new solution? I think there might be an original (acmsigmod?) article on how to build an effective interconnect layer. (I see some familiar elements in the code, but I cannot fully comprehend what it is)

[zhangyue1818]

Awesome! Could you please share some information about the architecture of the new solution? I think there might be an original (acmsigmod?) article on how to build an effective interconnect layer. (I see some familiar elements in the code, but I cannot fully comprehend what it is)

During performance testing, we identified the Motion node as a significant performance bottleneck. Further analysis revealed that the root cause stems from inefficiencies in the underlying IPC layer protocol implementation. To address this, we plan to enhance the IPC layer to improve overall system performance.

Currently, the IPC layer is tightly coupled with the database kernel, which makes implementing performance optimizations challenging and limits flexibility. As an initial step, we are decoupling the IPC layer from the database kernel. This separation will not only simplify future improvements but also enable independent testing and development of the IPC layer.

This commit represents foundational work—specifically, the decoupling of the existing UDP-based IPC layer from the database kernel—and lays the groundwork for subsequent performance optimization efforts.

[tuhaihe]

The following two files also need the license header:

[WARNING] Files with unapproved licenses:
  contrib/udp2/CMakeLists.txt
  contrib/udp2/ic_common/CMakeLists.txt

[zhangyue1818]

7e7c028

The following two files also need the license header:

[WARNING] Files with unapproved licenses:
  contrib/udp2/CMakeLists.txt
  contrib/udp2/ic_common/CMakeLists.txt

fix in 251adf4

[tuhaihe]

+1 for ASF license check.

[yjhjstz]

why not use std::mutex and std::lock_guard ?

[zhangyue1818]

Both ic_control_info.lock and trans_proto_stats.lock are initialized using initMutex(). The usage of ic_control_info.lock is highly complex, and replacing it with std::mutex and std::lock_guard would be challenging in the near term. In contrast, trans_proto_stats.lock has a much simpler usage pattern, and in the latest commit, it has already been successfully migrated to std::mutex and std::lock_guard. As the protocol implementation continues to evolve and the usage of ic_control_info.lock becomes simpler, we plan to gradually replace it with modern C++ synchronization primitives as well.
fix in 30b949c

[yjhjstz]

Could you please share some information about the architecture of the new solution by doc ?

[zhangyue1818]

Could you please share some information about the architecture of the new solution by doc ?

Describes the architecture and other aspects in README.md，see 94428f1