Negotiating ECE

[chenBright]

What problem does this PR solve?

Issue Number: resolve

Problem Summary:

The RDMA endpoint already declares the intent to do ECE (Enhanced Connection Establishment) negotiation (BringUpQp is gated by FLAGS_rdma_ece), but the existing implementation never exchanges ECE capabilities between the two peers.

What is changed and the side effects?

Changed:

This PR implements an end-to-end ECE negotiation in the v3 handshake.

• Client (RdmaHandshakeClientV3::SendLocalHello): query local ECE, store it in _outgoing_ece, advertise it in the v3 hello.
• Server (BringUpQp): apply the client's ECE during INIT->RTR (ibv_set_ece). After QP reaches RTS, ibv_query_ece to obtain the reduced/negotiated ECE (the subset both peers support) and store it in _outgoing_ece.
• Server (SendLocalHello → FillLocalRdmaHello): advertise the negotiated ECE in the reply hello.
• Client (BringUpQp): apply the server's reduced ECE during INIT->RTR.

Side effects:

• Performance effects:

• Breaking backward compatibility:

---

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow Contributor Covenant Code of Conduct.