Support more generic configurations

[RyuzakiKK]

If the remote stores are located in a server that has the following structure https://example.com/foo/version/store, for example when we need the version 20210104 we will use https://example.com/foo/20210104/store, and for the 20210105 we will use https://example.com/foo/20210105/store.

Right now Desync configuration file expects an exact match between the URLs. So for this use case we can't just write a single config.json because the store URL is not a fixed value.

I was thinking about supporting the wildcards * and ?, but because the entries can be URLs, Windows paths and Unix paths, I suppose this would end up being too complicated to handle correctly.

I think one possible solution would be to support the special value *. Essentially the default fallback in case nobody of the other specified entries matched.

For example:

{
  "store-options": {
    "https://192.168.1.1/store": {
      "client-cert": "/path/to/crt",
      "client-key": "/path/to/key",
      "error-retry": 1
    },
    "https://10.0.0.1/": {
      "http-auth": "Bearer abcabcabc"
    },
   "*": {
     "uncompressed": true
     }
   }
}

Maybe another option is to interpret the config entries as the prefix of the URLs/paths. So that, in the example above, https://10.0.0.1/ would match also https://10.0.0.1/foo/ and https://10.0.0.1/bar/.
I think that this second proposal would be slightly better, because would allow different configurations for different domains.

@folbricht What do you think? Before proposing a patch I wanted to hear your opinion.

[folbricht]

I definitely like the idea of supporting a more flexible config. Let's look at the options first:

1. As you said, it could be done by just comparing prefixes. It's probably the least flexible option. And in rare cases it could break backwards compatibility.
2. The most flexible would be to use regexp. Again, this isn't ideal since existing configs would have . in them and that would change the meaning of those. It'd be fine in most cases but not ideal.
3. A simple glob where things like *, ? and [] are supported. That could be built with https://pkg.go.dev/path/filepath#Match

So I think 3) may be the safest choice. There's two more things to watch out for though. The current config doesn't use an array, but a map. So there's no defined order and adding a default * at the end wouldn't work without changing the structure of the config file. Also, once you allow globs, it's possible that two entries could match a store string. I think it'd be best to error in that case rather than silently pick one.

[RyuzakiKK]

When I first evaluated the glob wildcards I think I missed that filepath had support for it. I opened a proposed solution in #209