snmp-ups: quiesce "unhandled ASN 0x80 received from ..." when we fall back to using the numeric value from last OID section

[jimklimov]

Closes: #1358

Per analysis in the ticket (thanks @smarsching), we sometime get OIDs to something that represents a constant, that should not really be resolved. When we recurse from nut_snmp_get_int (for an ASN_OBJECT_ID PDU type) we first loudly upslogx an error in the default case (the 0x80 seems to be ASN_CONTEXT, with no more context to indicate that this specific query went to a constant... or should the lack of other bits mean exactly this?) and then fall back to returning the last section of the OID as the desired number.

With this PR, the original nut_snmp_get_int() method body became the implementation of do_nut_snmp_get_int() with an added option to log the default case loudly (upslogx()) or quietly (upsdebugx()), and the nut_snmp_get_int() signature called by others is a shortcut to call this implementation with loud debugging. Recursing into itself for ASN_OBJECT_ID is done in quiet mode.

This way, I hope, we still log OIDs that are out of place in e.g. mapping tables, but would not make infinite system log noise for returned references like these.

[AppVeyorBot]

✅ Build nut 2.8.4.4286-master completed (commit 0feb1da11b by @jimklimov)

[smarsching]

@jimklimov Thank you very much for your efforts!

I didn’t find the time to test the changes this week, and next week I am out of office for a few days, so it most likely won’t happen before the week after.

[jimklimov]

ACK, thanks fir reaching out. This is merged by now, so when/if you do get to testing, you can at least follow the standard procedure as written, with master branch of the primary repository (e.g. not my fork).