Bug 765336 (GLUSTER-3604)

Right now, the translator API includes a "local" field in the
call_frame_t structure, which many translators use to hold their own
state across asynchronous calls/callbacks.  Typically, they GF_CALLOC a
translator-specific structure and stick the pointer into frame->local.
This does get freed automatically when the frame itself is freed, which
is ever so slightly convenient, but otherwise we have a situation in
which every single translator that touches a request incurs a whole
system-level malloc/free pair - not even benefiting from the pool
allocation used for the frames themselves.  Besides the cycles
consumed, this also has implications for page and cache warmth.

What I'm proposing is that each translator can provide an *optional*
new entry point which the translator infrastructure can use to query
the size of the structure that the translator will be using "local" to
hold.  That infrastructure can then walk the translator graph to
determine the total size of all such structures in the longest path, and
use a single malloc/free for all at once.  This might in some cases
result in allocating space for a structure that won't be needed, but in
the great majority of cases it would be more efficient than what we have
now.  It would also be more convenient, since translators that
implement the new query function wouldn't have to manage the
local-structure life cycle themselves.  Other translators could
continue to use the current method indefinitely.

I'd be willing to write the infrastructure code for this, and modify
some of the most commonly used translators to use it as examples.  Any
interest?