Using as() step is slowing down Gremlin Query dramatically

**Using as() step is slowing down performance of the Gremlin Query with some combinations**
specifically when Filter Segment is used, for example:
- around 500 milliseconds: `g.V().and( __.properties("amount"))`
- around 2 seconds: `g.V().as("MARKER").and( __.properties("amount"))`
Timing was measured by dedicated procedure, and is similar to the one reported by profile() step as samples below.

We have the same experience on our commercial JanusGraph system with big data, where performance of some similar queries with the Reference Markers are 5 x times slower than without it.

Interestingly, adding barrier(2500) step is able to improve performance, e.g.
- around 500ms: `g.V().as("MARKER").barrier(2500).and( __.properties("amount"))`

**Steps to reproduce using popular samples from JanusGraph documentation**
```
graph = JanusGraphFactory.open("inmemory")
mgmt = graph.openManagement()
timestamp = mgmt.makePropertyKey("timestamp").dataType(Integer.class).make()
amount = mgmt.makePropertyKey("amount").dataType(Integer.class).cardinality(Cardinality.LIST).make()
mgmt.buildPropertyIndex(amount, 'amountByTime', Order.desc, timestamp)
mgmt.commit()

for (int ii=0; ii < 100000; ii++) { bob = graph.addVertex(); bob.property("amount", 100, "timestamp", 1600000000); bob.property("amount", 200, "timestamp", 1500000000); bob.property("amount", -150, "timestamp", 1550000000); }

g = graph.traversal()
```

- around 500 milliseconds: `g.V().and( __.properties("amount").has("timestamp",P.eq(1600000000))).count().profile()`
- around 2 seconds: `g.V().as("MARKER").and( __.properties("amount").has("timestamp",P.eq(1600000000))).count().profile()`

Similar results are also for just simplified queries, however the difference is not that drastic in memory DB, however bigger in reality
- around 80ms: `g.V().count().profile()`
- around 90ms: `g.V().as("MARKER").count().profile()`

Start by reproducing the reported Gremlin traversals against the in-memory JanusGraph setup, comparing profile() results with and without as("MARKER") and barrier(2500). Trace the traversal and filter-segment processing involved in these entry points. Done means identifying and correcting the performance regression, with profile results showing the affected queries no longer incur the reported slowdown.

Written by the indexing model from the issue text.