feat: add metadata endpoint

[bacherfl]

This PR adds a new method and message definitions for retrieving metadata from a sync provider. What exactly the attributes of the metadata response are is up to the implementation of the sync service, as the response for the GetMetadata requests is a string map containing arbitrary keys. Examples for those attributes could be the name of the environment or the kubernetes cluster the service is running in

[toddbaert]

Seems clear and simple enough to me. I have 2 thoughts:

• do we want to do this as a separate RPC? The other option is to add it to SyncFlags
  • I personally think it should be a separate RPC (like in this PR), though it does make the implementation slightly harder
• do we want to add this to the evaluation service as well?
  • we can always do this later

[bacherfl]

Seems clear and simple enough to me. I have 2 thoughts:

• do we want to do this as a separate RPC? The other option is to add it to SyncFlags

  • I personally think it should be a separate RPC (like in this PR), though it does make the implementation slightly harder

• do we want to add this to the evaluation service as well?

  • we can always do this later

I would also agree that adding this as a separate endpoint is the better option here, since the metadata retrieved via this endoint will likely be mostly static (e.g. the environment or cluster the sync service is running in), and therefore would not have to be transmitted with each request, but rather during the initial handshake phase

[toddbaert]

Seems clear and simple enough to me. I have 2 thoughts:

• do we want to do this as a separate RPC? The other option is to add it to SyncFlags

  • I personally think it should be a separate RPC (like in this PR), though it does make the implementation slightly harder

• do we want to add this to the evaluation service as well?

  • we can always do this later

I would also agree that adding this as a separate endpoint is the better option here, since the metadata retrieved via this endoint will likely be mostly static (e.g. the environment or cluster the sync service is running in), and therefore would not have to be transmitted with each request, but rather during the initial handshake phase

Well, with streams you could just send that down the pipe once, at the init, but that would also be a complexity of it's own sort, since the client would have to understand that different payload type.

[toddbaert]

@Kavindu-Dodan @beeme1mr @thisthat anyone else have some opinions?

[beeme1mr]

A separate endpoint is fine with me.

[Kavindu-Dodan]

@Kavindu-Dodan @beeme1mr @thisthat anyone else have some opinions?

I am fine with a dedicated endpoint. Can't see any major disadvantage.