Remove FlowState and use a proxy pattern for that state

This is a pretty big change as it causes all read taps to be wrapped by a proxy, but it does remove a big wart: the global static FlowState map.

Thoughts on this one?

@cwensel Note the ProxyTap here. I had to resort to reflection to make this work due to the .id in Taps being private. It would be nice to have this ProxyTap idea supporting in cascading so that we can attach extra information to Taps we get at runtime.

> Note the following facts:
> 1) We are not "changing" and ids, we are initializing them in the constructor to be the same as the Id of the proxy. Can you comment as to why that is dangerous? It seems the tests pass?
> 
as of 2.5.6 the id is immediately initialized on construction and set as final. you can pull it up to the proxy (which i think sounds like a decorator), not the reverse.

this was a mistake on my part to not make it this way initially. my apologies for any confusion. 

> 2) As for adding Metadata, I would actually just the class I have here, ProxyTap. I can subclass proxytap and attach any data I like to a Tap passed to be by a user. The things I need to attach to the tap are: Source, TypedPipe going in or out of that Source, the scalding Mode this tap was associated with, and possibly more. So, I want to be able to have a
> 
> class MetadataTap<Meta, Config, Input, Output> extends Tap<Config, Input, Output> {
>   public MetadataTap(Meta metadata, Tap<Config, Input, Output> wrapping)
>   Tap<Config, Input, Output> getWrappedTap();
>   Meta getMetaData();
> }
> That would be great if I had that. This is what I have implemented in two steps (proxytap and a subclass of that I use when making the scalding graphs).
> 
> 


as of 3.0, we have already changed the type signature of Hfs to accommodate differing hdfs based platforms. we could go as far as introducing a new Meta type parameter to Tap. of course this complicates the belief by the raw Java folk Tap/Scheme should not have type parameters because they don't believe in nesting parent child relationships. which is a core pattern in the Tap framework (MultiSource/Sink, PartitionTap, etc)

having a Meta decorator is also an option. this promotes the nesting parent child relationship model to preserve type safety. this option lets us get the feature into 2.6

what might also be interesting is that we have introduced java level annotations that can be added to any property on a core java object (Tap/Scheme/SubAssembly/Operation) to help manage those values. Flow now also has a flow descriptor that can hold arbitrary information (like what SQL statements is this Flow running).

http://docs.concurrentinc.com/cascading/2.6/cascading-core/cascading/management/annotation/package-summary.html

if the annotations are on the Meta object, they can be utilized as well.

does Pipe/SubAssembly need a Meta decorator? 

--
Chris K Wensel
chris@concurrentinc.com
http://concurrentinc.com