self communication pattern

It is currently the case that an object in a dripline-python service cannot send requests to an endpoint in the same service. This is because the call stack send the request stops any python functions from processing the incoming request. There are a few pieces to resolving this:

1. We should re-evaluate the potential use of async, it may be possible to resolve blocking with those patterns (probably requires across the board refactoring to make everything async compatible)
2. The lower-level send methods should check if the target of the request is local, if so it should pass the request object to the request handling logic stack directly (rather than making a round trip to the broker). This places the resolution logic in the same call stack and avoid blocking.

There are some possible concerns:
1. The above could result in an infinitely recursive loop (which should be stopped by the python recursion depth limit). It is not clear superficially if this is something we need to detect and protect against, or just document and "let it fail" for a user to fix.
2. There could be cases where both a local and a remote consumer are expecting to receive a request, we need to make sure that the remote also gets it (for example, if I am running dl-mon to see all requests coming into some endpoint).
3. If the request is sent locally, the reply needs to also be processed locally such that the original caller receives the reply in the expected type and format. This also has the same concern as 2, namely that there could also be a non-local client expecting to receive the result.