Add something similar to DecodeResult.NOT_FOUND to ServiceInvocationHandler

[trustin]

A ServiceCodec can tell the session layer that the request doesn't actually belong to the enclosing Service so that the other Service takes over, by returning DecodeResult.NOT_FOUND.

It will be nice if ServiceInvocationHandler has something similar. For example, a user could bind an HttpFileService and a TomcatSerivce under the same path prefix. If HttpFileService fails to find the file, TomcatService could handle it, making it possible to serve the static resources using Armeria. (TomcatService could also handle the 404 response from Tomcat specially so that the next service takes over.)

/cc @delegacy

[delegacy]

Agreed. However, I'm not sure how to generalize a trigger to take over requests for the next service.

[trustin]

This issue will require two following changes:

• Make DecodeResult.NOT_FOUND not fail immediately. Let HttpServerHandler try again until it tries all matching services.
• Define a mechanism for ServiceInvocationHandler that does the same job with DecodeResult.NOT_FOUND.

Perhaps we could define some exception type? We have ServiceNotFoundException already, so we could use it for this purpose. It's actually the exception used when HttpServerHandler gets DecodeResult.NOT_FOUND, so it seems to make sense to me.

Another issue to consider is the case where a service wants to tell the session layer that the path does not exist and it does not want other services to take the request over. However, I'm not sure if we should consider this because usually they will just end up hitting the catch-all path mapping or making HttpServerHandler return 404.

[delegacy]

Another issue to consider is the case where a service wants to tell the session layer that the path does not exist and it does not want other services to take the request over. However, I'm not sure if we should consider this because usually they will just end up hitting the catch-all path mapping or making HttpServerHandler return 404.

I think we need to consider the case when a user does want the last service to catch 404 and response with the custom error page. In this case, propagation of 404 should not be done.

[trustin]

This actually was fixed in #60 slightly differently.