Add instrumentation to detect the route at the beginning of the spring request

[tylerbenson]

Instead of waiting till the handler is called, otherwise if a response is returned by a filter then the proper name wouldn't be set and would fall back to the URL.

I tried to add comments for the parts that are interdependent. Let me know if it's insufficient.

[devinsba]

I guess this doesn't have to implement Filter since it's not being used as one, but since we don't have access to the functional interfaces there doesn't really seem to be a better type in my mind

[tylerbenson]

Yeah, that was my thought also... If there's a better generic interface that takes a single argument I'd be happy to use that instead.

[dougqh]

Do we want log here? Add a health metric?

[tylerbenson]

I added a log statement, even though the exception is never thrown. If we had a better shared interface we could avoid the try/catch (filter doesn't actually need to implement the Filter interface).

[dougqh]

I realize this didn't change in this PR, but I'll ask anyway.

I'd expect scope.close to be inside of a finally block, but usually, it is not.
I'd actually expect XDecorator.beforeFinish to be inside a finally block as well.

Maybe, the first two lines don't typically raise exceptions; however, we might not know because of the suppress=Throwable.

Basically, I'm concerned that this code is not obviously correct. From looking around, this seems to be a general problem with our resource handling.

[tylerbenson]

It's true that exceptions thrown from our decorators could cause problems in many places... That should probably be addressed as a separate issue.