Feature/configurable statq

[fnuzzi]

Please ensure all items are complete before opening.

• [ x] Tick to sign-off your agreement to the IBM Contributor License Agreement
• You have added tests for any code changes
• [ x] You have updated the CHANGELOG.md
• [x ] You have completed the PR template below:

What

I am suggesting add a new configuration parameter MonitoredSTATQ which allows configure the STATQ (PUT,GET,OPENCLOSE,INQSET) for each queue object e.g. subscribe for only PUT and GET or any other combination

How

The reason is I have QMs with large number of queues and I am not really interested in some of those stats per queue. Here is an example of using only PUT,GET instead of all STATQ:
queues 2716
subscriptions 5445 instead of 10877
messages 5445 instead of 10867
There is no real difference in the zipped file size (10.5 MB instead of 11.7 MB) but a huge difference in subscriptions and messages generated during each publish interval. The difference is also big in terms of time series (with PUT,GET only I get more than 103.000 time series)

Testing

Performed test locally and verified in test environment.
Example 1:

• add to mq_prometheus.sh
  ARGS="$ARGS -ibmmq.monitoredSTATQ=PUT,GET"
• run mq_prometheus
• using MQ-Explorer verify only PUT,GET subscriptions are created for each local queue
  Example 2:
• do not add monitoredSTATQ. It defaults to "".
• run mq_prometheus
• using MQ-Explorer verify all subscriptions are created for each local queue
  Example 3:
• add to mq_prometheus.sh a "wrong" value:
  ARGS="$ARGS -ibmmq.monitoredSTATQ=PUT,GETx"
• run mq_prometheus
• you get following error:
  time="2020-04-20T11:48:59+02:00" level=fatal msg="Invalid value for monitored STATQ: Object pattern 'GETx' is not valid. Available values are 'GET OPENCLOSE INQSET PUT '"

Issues

Links to the github issue(s) (if present) that this pull request is resolving.

[ibmmqmet]

Thanks for providing this.

But I'm sorry, I'm going to reject this PR. Not because it's a bad idea but
a) changes to the "vendor" directory are not allowed (that's meant to be a fixed copy of the other prereq trees). The right way here would be a coordinated change with the real mqmetric package.
b) I've got other changes planned/in progress which will restructure some of the APIs into the mqmetric package so this would conflict and confuse those changes - one thing I want to do is move away from passing around lots of individual parameters and instead pass a single control block object naming all the queues, topics etc.

I will keep this in mind as I am doing that other work, and I might adopt the concept directly or perhaps slightly different detailed changes within both this and the mqmetric repo would be needed at that point.