Make getConfiguration serialization more robust

[jmatsushita]

In order to avoid this bug to reappear on a future dependency update that would revert https://github.com/synchrony/smsn/pull/68 , it would be good to:

• find out why {"empty":false,"mapType":"java.util.HashMap"} is returned sometimes during the getConfiguration action (possibly empty keys or values), check and fix exception handling upstream if needed
• ensure the payload doesn't have null keys before returning it in any case

[joshsh]

Note: assigned to self, but I may leave this issue idle for now, as I expect that I/O will be revamped before there is any need to bump the JSON dependency.

[joshsh]

...unless the bad configuration is occurring during ordinary operation, in which case merely tolerating it does not seem like the right thing to do. What are the minimal steps to reproduce the error condition?

[jmatsushita]

I may leave this issue idle for now, as I expect that I/O will be revamped before there is any need to bump the JSON dependency.

Sounds very reasonable.

What are the minimal steps to reproduce the error condition?

I don't have a clear path to reproduction, but I suspect that starting with a fresh gremlin/neo4j install with empty sources folder would yield the same error. In order to make this reproducible, I would probably go towards a more declarative installation process, either by upgrading the docker approach (which used to be my goto), or moving towards a nix-based approach (which is my current preferred approach with https://devenv.sh/).

I think it's a good idea to go this route as this also means it would open the path to setting up CI (with github actions for example) which would be useful if there's some level of contribution in the repo.