tchannel context

gistfile1.txt

poc here https://github.com/uber/tchannel-python/compare/stackcontext#diff-dcfe0a6e0e1f4a668fbb768aa62ba633R48

```

# Currently:
@tchannel.register
def handler1(req, resp, proxy):
    pass
    
# Proxy is strange, no clear purpose. Replace proxy with context, which
# contains information like parent trace id, span id, and transport headers.
   
# No StackContext magic happening, manually manage context for performance
@tchannel.register
def handler1(req, resp, context):
    # Downstream request has to pass context explicitly. Raise an error if 
    # we're outside of a StackContext and no context is provided.
    tchannel.thrift.call(
        kv_value.setValue("foo", "bar"),
        context=content,
    )
    
# StackContext case
@tchannel.register
def handler1(req, resp, context):
    # downstream request is going to find the current context on the StackContext
    tchannel.thrift.call(
        kv_value.setValue("foo", "bar"),
    )
    
    # still supports power-users who want to do things like inspect
    # the current request's TTL, caller name, etc. Make context a well-defined object:
    context.ttl
    context.caller_name
    
    # allow overriding *some* context fields on downstream 
    # requests (not caller name, for example):
    tchannel.thrift.call(
        kv_value.setValue("foo", "bar"),
        ttl=2,
    )
```

Why does it need to store the transport headers or TTL? Right now the only information that needs to be propagated is the tracing information, right?

Can we make the context argument optional; based on some flag you pass when registering?

@tchannel.register(...)  # no context needed
def handler(req, res):
    # ...

@tchannel.register(..., include_context=True)  # want access to context
def handler(req, res, context):
    # ...

And we shouldn't be raising an exception if not inside a stack context. That just means that the tracing/whatever information isn't available so we use defaults. For tracing, that means that we generate a new trace.

# No StackContext magic happening, manually manage context for performance

How would this work? The performance cost of using stack context is not in accessing the global. That's cheap. The cost is in entering and existing the context manager, and that's unavoidable because the stack context is installed when the handler is being called:

with StackContext(..):
    handler()

We may be able to use http://tornado.readthedocs.org/en/latest/stack_context.html#tornado.stack_context.NullContext for performance sensitive parts that don't mind 'forgetting' the stack context. Needs investigation.