Undesirable concurrent transaction handling

Since roughly Titan 0.4.x, we've maintained an integration test that tests a number of graph behaviors when related changes are made concurrently (using Cassandra and ElasticSearch as the backends for the graph). A lot of these cases are handled as expected, but there are a few that have been recurring problems (for instance, creating ghost vertices, even on single node setups). In most cases, transaction commits succeed and leave a weird state, instead of failing one of the transactions as desired.

An example of one of the test descriptions:

```
// Create an edge where the destination vertex has been deleted.
// Expected outcome: The second commit resurrects the edge. The edge has all of the same properties as the original
// edge (even those that weren't modified in the transaction that resurrected it), and the edge still originates
// from the correct vertex, but any attempt to access the destination vertex's properties invokes an
// IllegalArgumentException. The ghost vertex doesn't throw an exception when touching edges, however.
// Desired outcome: An exception is thrown upon commit of the modified property.
```

Most of the more troubling ones involve a deletion in one thread concurrent with a modification in another, where the modification resurrects the deleted edge/vertex.

Anyway, we have all of these tests, and would like to see the issues fixed. Right now they use a fair amount of our own scaffolding around JanusGraph and integration tests, so it would take some effort to rewrite them for JanusGraph alone. Would that be valuable? Is it worth putting up a PR that contains a bunch of test cases? Or would it be best to simply provide the scenarios to anyone who takes on this issue, and let them write tests that complement what JG already has (I haven't particularly checked what exists now)?

Start by reviewing the existing concurrent graph integration tests and the project’s JanusGraph test scaffolding, especially the Cassandra and Elasticsearch cases. Focus on concurrent deletions and modifications that resurrect edges or vertices; done means the relevant commits fail as intended instead of leaving ghost or inconsistent state.

Written by the indexing model from the issue text.