Add support for wildcard expressions in subscriptions and reads

[RickBullotta]

We need some type of wildcarding mechanism for subscriptions. Having to enumerate all of the elementIds is not ideal in large systems, plus it isn't "adaptive" when new objects are added that would satisfy the wildcard expression (e.g. a new device of type "X" is added to the system, and you want to subscribe to all instances of "X"

Wildcard expressions would also be useful for reads as well (both current value and historical value)

[jwise-mfg]

Good feature for vNext.

[aronsemle]

I agree with @RickBullotta. I think we should drop maxDepth from the current RFC and spec, and instead support a wildcard syntax in the future (vNext).

Right now, the RFC defines a maxDepth on some calls. The intent is the server can browse child objects and include them in read/browse/register. As an example, subscription /register takes maxDepth. The problem is /unregister does not (and shouldn't). This means a client can call /register with a maxDepth of 5, then they need to call /subscription/{id} to get the actual list of what was registered, and then pass that to /unregister. It creates asymmetry which isn't ideal.

It would be better to remove this now, and in the future add a wildcard syntax. This would allow /register and /unregister to be symmetric, more like an MQTT subscription, and overall be easier to implement and more flexible for clients.