Update to ck 0.3.3 and introduce git subtree for ck vendoring

[kev009]

First commit contains the changes necessary for ck 0.3.3. Would appreciate some peer review here!

• In upstream, ck_ring changed quite a bit. ck_ring_init() doesn't touch the buffer, and it was removed from ck_ring_t. Instead, a new opaque ck_ring_buffer_t must be separately initialized and is passed in to each enqueue() and dequeue(). https://github.com/sbahra/ck/commit/3edb523da5f6c9dcea41879ceb6643dcc7bde305

The rest is a switch to using git subtree to vendorize ck. For a good overview, http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/. IMO, this is the least smelly way to vendor something, carrying the full repo is fine, and this gives the full power of git for maintenance of the vendor branch.

[wez]

big diff! I'm leaning more to unbundling CK from the tree than adopting a different way to track the branch; when I originally pulled it in to the tree it was because it was easier to deal with some build integration problems, but I think that CK has made progress in that area now.

[kev009]

I agree in principle, I'd like to see ck become a first class lib.

I could do a --with-system-ck using autoconf for distros and people properly packaging if you want to keep the vendoring until the API stabilizes a bit. I'll ping Samy and see what the weather map looks like to see if this is necessary.

76056ca should be useful regardless.

[kev009]

After some more thought I'd rather spend effort on unbundling. Can you come up with a punch list of any fixes needed by the ck build?

[wez]

The code we have in-tree matches http://concurrencykit.org/cgit/cgit.cgi/ck/commit/?id=1237681a71ed24a9f66ccd541605bd14cd5d6253

Any differences we have are encapsulated in the logic that we use to configure CK in configure.ac; I think we "just" need to remove the code that sets up CK and replace it with code that extracts the relevant compilation flags from its .pc file.

If anything we need is missing from the .pc file, we'll need to get that added in the upstream CK before we can unleash the upgrade on folks.

Big API changes in CK could be an issue with distros; I noticed that homebrew now has a CK recipe. @sbahra may need to get more aggressive at bumping those more significant version numbers to reduce pain and/or allow multiple versions to co-exist.

[sbahra]

Yeah, once I hit 1.0, I'll have to start caring about this. It's getting close, probably sometime soon after I dump ck_ht.

[wez]

I'm going to close this pull request since we agreed that we want to move towards unbundling