Get rid of global usage in mlog module

[dcbaker]

mlog uses a lot of global state, which it needs to mutate. This leaves a lot to be desired, especially since we provide some getter/setters for this state, and some we just poke at directly. We really don't want to be poking directly, and some of the methods we have are actually less than ideal: setup/teardown pairs that could be replaced by context managers 100% of the time, for example.

The main patch, the first one, uses a private class to track the state, and exposes it's methods as module constants. This allows the API between the global variables version and the class version to remain unchanged (with a few small improvements). Then I've cleaned up some typing stuff.

[codecov[bot]]

Codecov Report

Merging #11074 (df98e65) into master (d17e3ce) will decrease coverage by 20.35%. The diff coverage is n/a.

:exclamation: Current head df98e65 differs from pull request most recent head cb0b635. Consider uploading reports for the commit cb0b635 to get more accurate results

@@             Coverage Diff             @@
##           master   #11074       +/-   ##
===========================================
- Coverage   71.24%   50.90%   -20.35%     
===========================================
  Files         212      207        -5     
  Lines       46393    45165     -1228     
  Branches    11022     9356     -1666     
===========================================
- Hits        33055    22990    -10065     
- Misses      10878    20135     +9257     
+ Partials     2460     2040      -420     

see 419 files with indirect coverage changes

[tristan957]

I reviewed this last week and it looked good to me. Really nice changes, especially the context manager bit :)

[tristan957]

@xclaesse wanna take a look at this after a rebase?

[xclaesse]

I like the idea of moving stuff to a class, but needs a big rebase indeed.

[dcbaker]

I did the rebase, but I haven't made any changes beyond rebasing

[tristan957]

I think it is worth merging with the current design and @xclaesse could provide a follow-up without the repetition. This has sat for a while already.

[xclaesse]

LGTM

[tristan957]

@xclaesse good to go!

[eli-schwartz]

Two of these commits clean up code that has just been refactored by the first commit. Maybe those commits should come first so that the refactoring has to do less?

[dcbaker]

I'm incredibly dis-inclined to rebase the log_once patch before the hidden state patch. It's going to be a non-trivial amount of work, it doesn't change the correctness of the series at any point, and at the end it lets use delete 1 line each from two patches

[eli-schwartz]

Thanks for letting me do the work for that anyway. :) My neatness freak appreciated it.