chore: separate server for each service

[yhl25]

• separate servers for each operation(map, reduce, mapstream, sink and sourcetransformer)
• introduced Server interface inside numaflow package, all the servers will implement this interface
• Separate proto files for each operation and created separate types for each server to avoid confusion
• Separate sock address for each operation
• refactored directories to avoid confusion between the operations
• refactored the interfaces exposed to users to remove handlers
• created separate types Message, MessageBuilder etc for each service.

fixes #74

[whynowy]

Can we bring the versioning back to the proto definition? I feel like it's not right by removing it. The versioning is used to have the ability to define different contract in the future, while with backward compatibility. As practices, most of the good projects define their proto contracts with versioning.

https://github.com/envoyproxy/envoy/blob/main/api/envoy/api/v2/core/protocol.proto https://github.com/solo-io/gloo/tree/main/projects/gloo/api/v1 https://github.com/dapr/dapr/tree/master/dapr/proto/components/v1 https://github.com/spiffe/go-spiffe/tree/main/v2/proto/spiffe/workload https://github.com/istio/api/blob/master/mesh/v1alpha1/proxy.proto

[vigith]

their proto files are complex; hence they need it? do we really have a use-case where we will use versioning?

[whynowy]

their proto files are complex; hence they need it? do we really have a use-case where we will use versioning?

Complexity shouldn't be a factor of doing versioning or not. Versioning give us a chance to run backward compatible code. Assume some day, there's a breaking change on the contract (v2), the platform code may have a chance to know which version of code the ud container is running, and use corresponding version of client to do the communication.

[vigith]

@yhl25, please do the non-critical asks in follow-up PR, i am going to merge this PR because it is a huge PR, and all major comments have been addressed.