[logging] ensure isEnabledFor implements the right semantics

[vchudnov-g]

We are guarding logging statements inside a check for _LOGGER.isEnabledFor(LEVEL) where LEVEL is typically (for now) std_logging.DEBUG, though we may use other levels, such as INFO, WARNING, in some messages.

As per the official docs, isEnabledFor and a function it calls, getEffectiveLevel, check whether a certain severity is handled by the current logger, and only traverse up the hierarchy if the logger's severity is NOTSET.

This does not seem to be the semantics we intend. If the current _LOGGER is set to level INFO, say, but propagation is on, and the parent logger is set to level DEBUG, we want _LOGGER.debug() statements to not be handled by _LOGGER but to be handled by its parent. This means the logging statements should execute, which means the guard statements should evaluate to true, which means we need a different function than isEnabledFor.

This is also relevant to the internal issue b/382299158 for logging encapsulation.

[parthea]

Bumping to P2. This is part of the logging feature but it does not block releases. As per the definition, Moderately-important priority. Fix may not be included in next release.