Add Response Labels

[krithika369]

This PR introduces a mechanism to set and retrieve labels from Fiber responses. This will make it possible to propagate arbitrary information up the call stack, which may be useful for associating additional information to logs and metrics involving Fiber components.

Main Changes (Passing Info Up the Call Stack)

• labels.go - Labels interface and LabelsMap as a concrete implementation, for use in the standard Fiber components.
• response.go - Adding label related getter / setter functions to the Response interface
• grpc/response.go, http/response.go - Respective implementation of the new labelling functions. The labels are stored using the Metadata for gRPC and Headers for http.
• routing_strategy.go - Add Labels as a return value to SelectRoute(). In addition, baseRoutingStrategy.getRoutesOrder() has been refactored to send back multiple values to the caller through routesOrderResponse struct. This simplifies the calling code in both eager_router.go and lazy_router.go. Success and Error responses from both types of routers now include the appropriate labels.
• Updated integration tests (integration_test/integration_test.go) and unit tests.
• Updated sample routing strategies in extras/, README.md.

Passing Info Down the Call Stack

In Fiber, traditionally, the request context has been used to achieve this. Within the Lazy Router, since operations happen sequentially, the labels generated by getRoutesOrder can now be passed downstream (when calling the routes) via the request context as well. To facilitate this, new context key type has been added to interceptor.go.

Other Changes

• go.mod - Move to Go 1.18
• lazy_router.go (line 102) - Return empty routes error if no route returned a successful response. Previously, in this scenario, we were hitting timeout from the upstream component as nothing would be returned from the lazy router.

[leonlnj]

took some time trying to understand the removal of errCh from getRoutesOrder and the handling changes in eager and lazy. LGTM, thanks!

[leonlnj]

probably not related to this PR, but I think this part is abit fragile or with implicit assumption that fallback is an array returned.

Intuitively to me, scenarios are

1. No primary nor fallback
2. Primary with no fallback
3. Primary with fallbacks.

For scenario 2, it make sense to me that its nil-able, since there are no fallbacks as there is only one route. This is expecting fallbacks to be returned as an empty slice when there is no fallback nor error.

It make more sense to create an empty slice, append route and fallbacks if they are not nil instead of using routes := fallback as returning nil when there are no fallback seems valid to me.

Hope i didnt understood anything wrong 😅

[krithika369]

Your understanding of the scenarios is correct. In addition, there can also be:
4. No primary route, with fallback (which we use in Turing - the fallback will always be set if there is a default route.). Although the handling of the primary vs fallbacks is not very different upstream, in the Fiber component.

Thanks for raising the concern about the nil slice. I tried to test my understanding and it's actually not a problem. This article summarizes the behavior: https://freshman.tech/snippets/go/nil-vs-empty-slices/#whats-the-difference

The in-built functions all work the same, even for a nil slice. The part that differs apparently is if your JSON encode it.

[leonlnj]

Oops left another comment, other than that LGTM!

[krithika369]

Thanks for the review @leonlnj ! Merging now.