sensor_rpmsg.c:Fix that "stub" will be created when local core only has subscribers.

[Otpvondoiats]

Summary

Bug fix, After the ap core subscribes to the 25hz batch 120ms data of the sensor core, it switches to the cp core and subscribes to the 50hz batch 120ms sensor core data. At this time, the data subscribed by the AP will be abnormally lost (12.5hz). Mainly because ap subscribes to sensor core data earlier than cp. The subscription of cp will be broadcast to the ap core at the same time, and the corresponding "path" already exists under "/dev/uorb" of ap. Thus the ap will create a "stub".
There are some restrictions on the creation of "stub" to avoid this situation.

Impact

Cross-core communication and persistent topics

Testing

• build
  PC:ubuntu2004, X86,SIM
  rpserver and rpproxy open uorb config

./build.sh nuttx/boards/sim/sim/sim/configs/rpserver -j16
./build.sh nuttx/boards/sim/sim/sim/configs/rpproxy -j16

• order:

1. rpserver
2. rpproxy

[lupyuen]

[Experimental Bot, please feedback here]

Yes, the PR generally meets the NuttX requirements, but could use some improvements:

Strengths:

• Summary: Clearly describes the bug, its root cause, and the proposed fix.
• Impact: Identifies the relevant areas affected (cross-core communication, persistent topics).
• Testing: Provides build environment details and test procedure.

Areas for Improvement:

• Impact:
  • User Impact: Will this fix change any user-facing behavior? Be explicit (YES/NO) and describe if necessary.
  • Build Impact: Be explicit (YES/NO). If YES, explain any required build process changes.
  • Hardware Impact: Be explicit (YES/NO). If YES, specify affected architectures, boards, or drivers.
  • Documentation Impact: Be explicit (YES/NO). If YES, clarify what documentation needs updating and whether it's included in the PR.
  • Security Impact: Be explicit (YES/NO). Briefly explain any security implications.
  • Compatibility Impact: Be explicit (YES/NO) for backward, forward, and interoperability. Explain any potential issues.
• Testing:
  • Logs: The "before" and "after" logs are placeholders. Provide actual log snippets that demonstrate the bug and its resolution. This helps reviewers understand the impact and validate the fix.

Recommendations:

1. Expand the "Impact" section with explicit YES/NO answers and detailed descriptions where necessary.
2. Replace the placeholder logs in the "Testing" section with real log output showing the problem before the fix and the correct behavior after.

By addressing these points, you'll provide a comprehensive and informative PR that's easier for reviewers to assess and approve.