Connectivity events and API

[steils]

Connectivity status and events support for zenoh-pico, introduced in eclipse-zenoh/zenoh#2301

• Add connectivity info and listener APIs for transports/links.
• Implement transport/link connectivity events on peer connect/disconnect.
• Enable this feature via Z_FEATURE_CONNECTIVITY (requires
  Z_FEATURE_UNSTABLE_API).
• Add test z_api_connectivity_test.
• Support the feature in z_info example.

Related Issues

#333
#369
#1007

---

🏷️ Label-Based Checklist

Based on the labels applied to this PR, please complete these additional requirements:

Labels: new feature

🆕 New Feature Requirements

Since this PR adds a new feature:

• Feature scope documented - Clear description of what the feature does and why it's needed
• Minimum necessary code - Implementation is as simple as possible, doesn't overcomplicate the system
• New APIs well-designed - Public APIs are intuitive, consistent with existing APIs
• Comprehensive tests - All functionality is tested (happy path + edge cases + error cases)
• Examples provided - Usage examples in code comments or separate example files
• Documentation added - New docs explaining the feature, its use cases, and API
• Feature flag considered - Can the feature be enabled/disabled for gradual rollout?
• Performance impact assessed - Memory, CPU, storage implications measured
• Integration tested - Feature works with existing features

Consider: Can this feature be split into smaller, incremental PRs?

Instructions:

1. Check off items as you complete them (change - [ ] to - [x])
2. The PR checklist CI will verify these are completed

This checklist updates automatically when labels change, but preserves your checked boxes.

[github-advanced-security]

Cppcheck (reported by Codacy) found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[gmartin82]

I have some concerns about style inconsistencies here that should be cleaned up one way or another.

I’m also concerned about the introduction of goto, which the existing codebase has generally avoided to date. While goto can sometimes make control flow cleaner in C (and I think it does in this case), MISRA C:2023 (e.g. rule 15.1) discourages its use, and I do not think we should start introducing it without an explicit decision on whether we want to allow that pattern going forward. At the moment this feels inconsistent with the current style of the codebase.

[steils]

I have some concerns about style inconsistencies here that should be cleaned up one way or another.

I’m also concerned about the introduction of goto, which the existing codebase has generally avoided to date. While goto can sometimes make control flow cleaner in C (and I think it does in this case), MISRA C:2023 (e.g. rule 15.1) discourages its use, and I do not think we should start introducing it without an explicit decision on whether we want to allow that pattern going forward. At the moment this feels inconsistent with the current style of the codebase.

Replied in the code comment. Repeating here:

Using gotos here is a usual C-style rollback path, to avoid duplicating lots of code on error paths, it improves readability in general.
MISRA C generally discourages goto, but doesn't ban it. Structured, forward-only jumps to a common cleanup/rollback label in the same function is a usual pattern in C. See MISRA C:2023 15.2 and later, in particular 15.5 (having the single point of exit is why we use goto here).

[milyin]

The example doesn't demonstrate listeners functionality unlike examples in other binding, e.g. https://github.com/eclipse-zenoh/zenoh-c/blob/main/examples/z_info.c
But this is minor and can be added in separate update.
Other looks good to me