This is looking good. I like the proposed configuration file details.
I'm not worried about not setting the two timeouts separately; in fact, I'm not sure it's a good idea at all because it is complicated to have something set in two places - easy to make mistakes.
We can keep compatibility by setting via this first, then proceeding with the defined fuseki: settings. We can't stop ARQ.queryTimeout because there are are other ways to set it.
We can have an ordered hierarchy of setting:
– Global (cmd line settings) – Server – Service
which if set in that order, means the more specific one wins.
One issue is the commandline --timeout X or --timeout X,Y which is setting ARQ.queryTimeout (in ms).
We could simple deprecate and replace with --defaultTimeout and --maximumTimeoutOverride but the command line is more about easy setup, usually without config file. I see --timeout X as being the important case; put in some sort of timeout to guard aginst errant queries.
Seconds are a better choice. Adding units (e.g. "20ms") seems excessive for fuseki and can be done with fractional settings. The ARQ API uses millis by default because it is common in APIs however network use and very fine grained timeouts don't make a lot of sense.
We could take over --timeout as the initial setting (and the config file overrides) of both fuseki:defaultTimeout and fuseki:maximumTimeoutOverride, and migrate to seconds by assuming (with warning) X000 is ms. So if you want to do simple things, the command line is enough but complicated mixes of defaultTimeout and maximumTimeoutOverride need to be done with a configuration file.