Bump gremlin version

[velo]

@mpollmeier Any idea why this one test is breaking? https://travis-ci.org/mpollmeier/orientdb-gremlin/builds/131342538#L466

[coveralls]

Coverage increased (+0.2%) to 81.151% when pulling cddc7ef22fbc470eb56114fe5dd9a32874422f7e on velo:gremlin-3.2.0 into 6fa82eb1e2b740628b9089a0b68cea48c29e90af on mpollmeier:master.

[mpollmeier]

@velo no i don't, but I'm guessing it's some .equals or .hashCode implementation that's broken? to debug you'll have to bisect which o the contained object is apparently different...

just for context, copying the error message here

SerializationTest$GryoTest.shouldSerializeTree:245 The objects differ expected: 
org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[#11:0]={v[#12:0]={vp[name->lop]={}}, v[#11:1]={vp[name->vadas]={}}, v[#11:2]={vp[name->josh]={}}}}> but was: 
org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[#11:0]={v[#12:0]={vp[name->lop]={}}, v[#11:1]={vp[name->vadas]={}}, v[#11:2]={vp[name->josh]={}}}}>

[ihoro]

As I see OrientVertexProperty (within before) is not equal to DetachedVertexProperty (within after). Both have equal before.key=after.label and before.value=after.value, but before.element != after.vertex due to the latter one is null. This new test fails even if we bump to 3.1.2-incubating.

[velo]

Ain't equals or hashcode...

Tree.equals() as a matter of fact uses AbstractMap.equals()... so that check if all entries are equal... some entries are trees, which make this method recurse a few times. At some point, the original object has a tree and the one it's being compare to is null.

The left side tree is just empty and the right side is null.... I think the actual bug is on the serializer that is not deserializing any empties

I wonder if I should just ignore this test?

[coveralls]

Coverage increased (+0.2%) to 81.151% when pulling 448708ea0340e7288599fb18fbac2d8db199c259 on velo:gremlin-3.2.0 into 6fa82eb1e2b740628b9089a0b68cea48c29e90af on mpollmeier:master.