feat(framework) Add client metadata in grpc connection

[kuchidareo]

Issue

Description

This PR addresses the need to enhance federated learning (FL) by transmitting client metadata, such as CPU and memory specifications, via gRPC communication. The metadata will be used by the ClientManager to better select clients based on device capabilities, enabling more optimized FL strategies like heterogeneous federated learning (heteroFL).

Related issues/PRs

Issue #4339
Relates to #550

Proposal

Explanation

1. Adding a new attribute to the FlowerServiceStub.Join function to transmit metadata and retrieve it server-side using the invocation_metadata function.
2. Modifying other transport types' attributes for compatibility with this update.
3. Registering the metadata in the GrpcClientProxy as a class attribute, allowing for optimized client selection based on the received metadata.

Checklist

• Implement proposed change
• Write tests
• Update documentation
• Make CI checks pass
• Ping maintainers on Slack (channel #contributions)

Any other comments?

[kuchidareo]

I talked with Chong Shen from Flower in the Slack contribution channel.
This metadata feature will be reviewed after refactoring API.

This is the chat history:

---

Chong Shen
Yesterday at 10:39 PM
Hello
@Reo Kuchida
, thanks for this PR! I've flagged it internally. AFAIK, we use gRPC-rere more than gRPC-bidi. Are you working on a project that requires this functionality in Flower now?

Reo Kuchida
Today at 12:57 PM
HI!
I usually use bidi and, Yes. I need this function to optimize FL in heterogeneous conditions.
I just reviewed the gPRC-rere code. It looks like we can add metadata in the same way as with bidi.
unary_unary call function has also metadata attribute.
I can implement that as well if needed!

Chong Shen
36 minutes ago
Thanks for looking into this
@Reo Kuchida
. We agree that having this metadata will be useful. But, we have plans to eventually deprecate gRPC-bidi in favour of gRPC-rere.
In terms of implementation, there's also ongoing work to refactor our internal APIs. So, we'll likely defer merging your PR as it stands until our refactoring is complete. Would you be open to adjusting your PR once we finish?

Reo Kuchida
32 minutes ago
sure!
❤️
1

Chong Shen
16 minutes ago
Perfect! We'll keep you posted on our updates. Thanks for contributing!
:flwr:
1

---

[WilliamLindskog]

@chongshenng, are we planning to merge this?

[chongshenng]

@WilliamLindskog Not quite ready yet! We're still in the midst of refactoring. Target to incorporate this in Q2.