Fix logging.info and state transitions in LoggingMachine

[ionodeionode]

Fixes #1836.

This PR addresses the issue where logging.info and other logging levels were not correctly updating the logger level during state transitions.

Changes:

• Explicitly set self._logger.setLevel() in before_enable_info, before_enable_debug, etc.
• Standardized transition methods (disable_info, disable_debug, etc.) to use self.enable_default() to ensure consistent state reset.
• Updated before_enable_default and before_enable_info to correctly toggle self._stream_formatter.set_trace().

Verified with a test script simulating both CLI flag and manual set_info calls.

[thewhaleking]

I think this is fine, but I want @basfroman's opinion aswell.

[basfroman]

Thanks for looking into this!
I reviewed the changes in detail and have some concerns:

1. disable_* transitions replaced with plain methods

Converting disable_trace, disable_debug, etc. from statemachine transitions to regular methods means before_transition / after_transition hooks no longer fire for these events. This skips _listener.stop() / _listener.start(), which every other transition relies on. It also silently removes the before_disable_* / after_disable_* callbacks.

2. set_trace(True) in before_enable_info

Info-level logs shouldn't use trace formatting (name:filename:lineno). This would change the output format for all Info-level messages, which seems unintentional.

3. Redundant setLevel calls in before_enable_trace, before_enable_debug, before_enable_warning

The for logger in all_loggers() loop already covers self._logger (there's no _primary_loggers filter in these methods), so the explicit self._logger.setLevel(...) before the loop has no effect.

4. set_trace(False) in before_enable_default -- this one is valuable

This is a good defensive addition. Currently we rely on before_disable_* callbacks to reset the trace formatter, but if enable_default() is called directly (not via disable_*), the formatter state could be stale. I'd suggest we keep this single change.

The original issue #1836 was resolved in 8.4 via #2366 - is there a specific scenario you're still seeing with the current code?

Could we scope this PR down to just the set_trace(False) addition in before_enable_default (bittensor/utils/btlogging/loggingmachine.py line 416)?