fix(service): add proxy_data stub and fix ProvidedServices count trac…

[Chahult]

Based on v0.2.1 tag:

• Add proxy_data.h: OptionalProxyData alias for Optional
• Add proxy_data cc_library to score/mw/service/BUILD
• Fix ProvidedServices Add() to increment count_ so Count() returns the actual number of added services (was always returning 0)
• Fix Swap() to exchange count_ values
• Add private count_ member

[castler]

Can you please elaborate what we are trying to achieve with this changset?

The current mw::service implementation is just a bare frontend that is there for working compilation. We are right now working of the open sourcing of the current implementation.

If this was rather just some try-out PR, maybe we can mark it as "draft"?

[Chahult]

Can you please elaborate what we are trying to achieve with this changset?

The current mw::service implementation is just a bare frontend that is there for working compilation. We are right now working of the open sourcing of the current implementation.

If this was rather just some try-out PR, maybe we can mark it as "draft"?

config_management's unit tests use mw::service types from the communication library. Two concrete problems were hit:

1.ProvidedServices::Count() always returned 0 — Add() was never incrementing the internal count_ member, so any test checking how many services were registered would always see 0 regardless of how many were added. Swap() also didn't exchange count_ values.

2.proxy_data.h / OptionalProxyData didn't exist — config_management's code uses OptionalProxyData (an alias for Optional), but the file was missing from score/mw/service/.

Both are in the current bare-frontend placeholder implementation of mw::service. The PR adds the missing header and fixes the broken counter so config_management's unit tests can compile and pass correctly

[Chahult]

Can you please elaborate what we are trying to achieve with this changset?

The current mw::service implementation is just a bare frontend that is there for working compilation. We are right now working of the open sourcing of the current implementation.

If this was rather just some try-out PR, maybe we can mark it as "draft"?

This PR is a prerequisite for our unit test traceability work in config_management (eclipse-score/config_management#30)
Would appreciate a review so we can proceed. Happy to adjust if there's a preferred approach.

[Chahult]

@castler @LittleHuba Please review

[LittleHuba]

Unlocked the workflows for you. You are at least missing the update of our visibility checker.
Once all your workflows are green, we'll do a review.

[Chahult]

Unlocked the workflows for you. You are at least missing the update of our visibility checker. Once all your workflows are green, we'll do a review.

Unlocked the workflows for you. You are at least missing the update of our visibility checker. Once all your workflows are green, we'll do a review.

Could you please Unlock the workflow again