To Introduce Transaction Context to Allow Per-Transaction Configuration In JanusGraph Storage Plugin

**New Feature and Use Case**

In JanusGraph-FoundationDB storage plugin, we like to have the following features to greatly improve functionality and performance:
*Allow the application to provide the hint that “the query is read-only” and thus we can use pre-fetching Global Read Version (GRV) to reduce query latency. In 3-datacenter deployment, we found that query latency can be reduced with 50 ms from this optimization.
*Allow the application to choose different transaction modes. The “serializable” mode is desired for “write-related queries”, but for “read-only queries”, the application may choose “read_committed_with_write” mode to circumvent the 5-second transaction time limit imposed by FoundationDB today.

To achieve the above improvement, we will need to have a Transaction Context object to be associated with the JanusGraph Transaction, so that the above query optimization configuration parameters can be specified in the Transaction Context and is associated with each individual transaction (query). Note that read-only queries and write-related queries can concurrently be processed in the same Graphdb.

Today, all of the JanusGraph configuration parameters are set at the JanusGraph process start-time from the property file “janusgraph.properties” or from the “store features” set by the Store Manager. Both mechanisms can not support per-transaction customization.

The proposed change is on JanusGraphTransaction interface to have two additional methods (get/set):

```
class TransactionContext {
private Map options;
public TransactionContext setOption (String key, Object val);
}

//defined in org.janusgraph.core
interface Transaction {
void setContext (TransactionContext context);
TransactionContext getContext();
}

```

**Application Coding Related Changes**

With the above change, from the application perspective, the current code given at JanusGraph architecture’s [Transaction section](https://docs.janusgraph.org/basics/transactions/):

```
graph = JanusGraphFactory.open("berkeleyje:/tmp/janusgraph")
juno = graph.addVertex() //Automatically opens a new transaction
juno.property("name", "juno")
graph.tx().commit() //Commits transaction
```

will be changed to have one additional line:

```
graph = JanusGraphFactory.open("berkeleyje:/tmp/janusgraph")

graph.tx().setContext(new TransactionContext().addOption(“key1”, “value1”));
juno = graph.addVertex() //Automatically opens a new transaction
juno.property("name", "juno")
graph.tx().commit() //Commits transaction
```

And for the threaded transaction, similarly the current code:

```
threadedGraph = graph.tx().createThreadedTx();
threads = new Thread[10];
for (int i=0; i

Start with the org.janusgraph.core transaction interface and StandardJansuGraphTx.java, which the issue identifies as the main change points. Review the transaction examples and existing transaction behavior, then define completion around per-transaction context access, ordering enforcement for setContext(), and preserving existing storage-plugin behavior.

Written by the indexing model from the issue text.