fix(api): incorrect field mappings in GRPC GetStatsInfo and GetNodeInfo

[xxo1shine]

What does this PR do?
Node and network API responses populated two fields from the wrong source values because of copy-and-paste mapping errors.
Map needSyncFromPeer from the corresponding peer state and assign UDP inbound traffic to the udpInTraffic protobuf field.

Fixes #6926

Why are these changes required?

This PR has been tested by:

• Unit Tests
• Manual Testing

Follow up

Extra details

[lvs0075]

Since both issues are caused by errors in manual field mappings, could we also audit similar POJO-to-protobuf conversions for duplicated, swapped, or omitted fields? I noticed two related cases: NodeInfoService maps syncFlag from peerConnection.isDisconnect(), although syncFlag indicates whether the peer is synchronizing, and NetMetricManager#getNetProtoInfo() does not map LatencyDetailInfo.witness to the protobuf builder. Could we verify and fix these cases and add corresponding regression tests?

[bladehan1]

[NIT] Test isolation backlog

1. Make the traffic sentinels independent of global meter history. MetricsUtil keeps a static MetricRegistry, while BaseMethodTest resets the Spring context and Args but not that registry. Adding fixed amounts therefore does not guarantee that the four final cumulative counts remain distinct; prior activity in the same test JVM can make one of the assertNotEquals checks fail even when the mapping is correct.

Suggestion: derive marks from captured baseline counts so the resulting values are deterministic and distinct, or swap in and restore a test-scoped registry instead of relying on cumulative global totals.

[xxo1shine]

I checked how these meters are used in the test suite. Currently, no other tests write non-zero values to these four traffic meters. This test sets four distinct counts immediately after starting the application and reads the results before any actual network traffic can be generated. Therefore, although the MetricRegistry is static, there is no historical data in the current test execution path that could cause these counts to collide, so the fixed sentinel values remain deterministic and distinct. Based on this, I do not think the test needs any additional changes at this time.

[xxo1shine]

Since both issues are caused by errors in manual field mappings, could we also audit similar POJO-to-protobuf conversions for duplicated, swapped, or omitted fields? I noticed two related cases: NodeInfoService maps syncFlag from peerConnection.isDisconnect(), although syncFlag indicates whether the peer is synchronizing, and NetMetricManager#getNetProtoInfo() does not map LatencyDetailInfo.witness to the protobuf builder. Could we verify and fix these cases and add corresponding regression tests?

I have completed a comprehensive audit of similar manual POJO-to-protobuf field mappings across the codebase. So far, the only additional issues I found are the two you identified: the incorrect source for syncFlag and the missing mapping for LatencyDetailInfo.witness. I will fix both issues in this PR and add the corresponding regression tests. Thank you for the thorough review.