Namespace support for `nomadService(s)`

[cmd-johnson]

When using the nomadService or nomadServices functions, only services from the default namespace are returned. It would be nice if we could support querying services from other namespaces (or even all namespaces via *).

The nomadVar family of functions all already support namespaces using the following syntax: nomadVar "path/to/variable@namespace.region". nomadService supports a similar format like nomadService "tag=value.service_name@region".

Possible solutions

1. Ideally we could extend the nomad service query syntax to match the one of nomadVar and get "tag=value.service_name@namespace.region". However, that would break backwards compatibility because right now the region is assumed to appear right after the @. Changing the regex to assume that @x would be a region x and @x.y would be namespace x and region y would break existing setups, because regions may contain ., so we can't assume anything before the . is a namespace.
2. We could add two new functions with the same functionality as nomadService and nomadServices, but with support for namespaces. Those could use an updated query syntax matching the one of nomadVar.
3. Since the service name can't contain a ., we could use a syntax like service_name.namespace@region. This is still confusing when seen side-by-side with a nomadVar invocation.
4. Use a different separator than @ and . for declaring the namespace.
5. We could swap namespace and region to keep the backwards compatibility, but that is strange when seen side by side with a nomadVar invocation (nomadVar "var@namespace.region" vs nomadService "service@region.namespace").
6. The namespace could be passed as an additional (optional) parameter to the nomadService and nomadServices functions:
   • nomadServices currently takes 0 or 1 parameters. We could add an optional second parameter, e.g. nomadServices "region" "namespace".
   • nomadService has two possible ways of invocation, either with 1 or 3 parameters. Adding an additional optional namespace parameter to each of those overloads would be possible without any ambiguities.

I think breaking backward compatibility is out of the question, so 1. is out. I'm also not a big fan of the almost the same as nomadVar but not quite syntaxes (i.e. 3., 4. and 5.). 6. would be possible but would lead to further deviation from nomadVar, so my preferred solution right now would be 2..

I'd be happy to write up a PR once there's a consensus regarding the route to take.

Related Issues

hashicorp/nomad#14177