Traversal binding of dynamically created graphs are not propagated in multi-node cluster

Nobody has claimed this yet.

Following the discussion on the user list, we report two probably related issues:
1. Using a single Gremlin Server, for a new dynamic graph "graph1" created from a Gremlin Console with ConfiguredGraphFactory.createConfiguration(map), the binding graph1 and graph1_traversal do not appear for a new connection. On the new connection, the new graph is visible from ConfiguredGraphFactory.getGraphNames(). Expected behaviour only occurs if the new dynamic graph is created with ConfiguredGraphFactory.createTemplateConfiguration(map), followed by ConfiguredGraphFactory.create("graph1").

2. If two Gremlin Server instances share the same ConfigurationManagementGraph on a distributed storage backend, if a new dynamic graph is created from a Gremlin Console connected to the first server using the TemplateConfiguration, bindings for this new graph do not appear on a new connection (after 20 seconds) to the second Gremlin Server, even though the new graph is visible from ConfiguredGraphFactory.getGraphNames() in both Gremlin Consoles. This second issue has no easy workaround if the Gremlin Servers are accessed via a load balancer.

This can be reproduced on:
- Version: 0.5.3
- Storage Backend: cql and inmemory
- Mixed Index Backend: None
- Link to discussed bug: https://lists.lfaidata.foundation/g/janusgraph-users/topic/traversal_binding_of/81581654

The first issue can be reproduced with a single Gremlin Server and single Gremlin Console by playing the [bindingShouldExistAfterGraphIsCreated()](https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-server/src/test/java/org/janusgraph/graphdb/tinkerpop/ConfigurationManagementGraphServerTest.java). This test fails if a new configuration is created with ConfiguredGraphFactory.createConfiguration(map). This can be done manually by using the config files:
[gremlin-server-configuration-inmemory.yaml.txt](https://github.com/JanusGraph/janusgraph/files/6254619/gremlin-server-configuration-inmemory.yaml.txt)
[janusgraph-inmemory-configurationgraph.properties.txt](https://github.com/JanusGraph/janusgraph/files/6254617/janusgraph-inmemory-configurationgraph.properties.txt)

The second issue can be reproduced with two Gremlin Servers and two Gremlin Consoles, using the following config files:
[gremlin-server-configuration8185.yaml.txt](https://github.com/JanusGraph/janusgraph/files/6254625/gremlin-server-configuration8185.yaml.txt)
[gremlin-server-configuration8186.yaml.txt](https://github.com/JanusGraph/janusgraph/files/6254627/gremlin-server-configuration8186.yaml.txt)
[janusgraph-cql-configurationgraph.properties.txt](https://github.com/JanusGraph/janusgraph/files/6254632/janusgraph-cql-configurationgraph.properties.txt)
[remote8185.yaml.txt](https://github.com/JanusGraph/janusgraph/files/6254633/remote8185.yaml.txt)
[remote8186.yaml.txt](https://github.com/JanusGraph/janusgraph/files/6254635/remote8186.yaml.txt)
The cql backend was started using the bin/janusgraph.sh script (ignoring its gremlin server on port 8182 and the ES service).
The TemplateConfiguration used was:
```
map = new HashMap();
map.put("storage.backend", "cql");
map.put("storage.hostname", "127.0.0.1");

```

Start with janusgraph-server/src/test/java/org/janusgraph/graphdb/tinkerpop/ConfigurationManagementGraphServerTest.java and reproduce bindingShouldExistAfterGraphIsCreated() using the supplied in-memory configuration. Compare dynamic graphs created with createConfiguration(map) and createTemplateConfiguration(map), then reproduce the two-server CQL case with the linked configuration files. Done means traversal bindings for a newly created graph appear on new connections to one server and to both servers.

Written by the indexing model from the issue text.