log: allow --vmodule to downgrade the log level

[MariusVanDerWijden]

This PR allows --vmodule to also downgrade the log level for packages. closes #30717

This does have some performance implications that I'm not sure about yet

Before

 ./build/bin/geth --dev --vmodule="*=1" console
WARN [04-01|12:38:38.561] The flag '--vmodule' is deprecated, please use '--log.vmodule' instead
INFO [04-01|12:38:38.569] Starting Geth in ephemeral dev mode...
WARN [04-01|12:38:38.569] You are running Geth in --dev mode. Please note the following:

  1. This mode is only intended for fast, iterative development without assumptions on
     security or persistence.
...

After

./build/bin/geth --dev --vmodule="*=1" console
ERROR[04-01|12:37:46.896] Head block is not reachable
Welcome to the Geth JavaScript console!

[MariusVanDerWijden]

Benchmark:

func BenchmarkGlog(b *testing.B) {
	out := new(bytes.Buffer)
	glog := NewGlogHandler(NewTerminalHandlerWithLevel(out, LevelTrace, false))
	glog.Verbosity(LevelCrit)
	logger := NewLogger(glog)
	logger.Warn("This should not be seen", "ignored", "true")
	//glog.Vmodule("logger_test.go=5")
	for i := 0; i < b.N; i++ {
		logger.Trace("a message", "foo", "bar")
	}
}

This PR:

With vmodule disabled:
BenchmarkGlog-14 370532622 3.763 ns/op 0 B/op 0 allocs/op
With vmodule enabled:
BenchmarkGlog-14 2653554 406.2 ns/op 151 B/op 0 allocs/op

Master:

With vmodule disabled:
BenchmarkGlog-14 307312317 3.775 ns/op 0 B/op 0 allocs/op
With vmodule enabled:
BenchmarkGlog-14 2882396 436.6 ns/op 279 B/op 0 allocs/op

So it seems there's almost no performance difference between this PR and master

[MariusVanDerWijden]

The size of the map will at max be 20.000 items, (rough count of every time we call log), so 20.000*64*2 = 2MB (if all logs we have in the code would be hit)

[fjl]

I guess this works because the logger calls Enabled first to check for the fast path.

[fjl]

BTW, any reason why we are not forwarding the context parameter into the sub-logger?

[jwasinger]

If we set vmodule GlogHandler.override will be set, so Handle will always be called. If the global verbosity is changed in the console after a log is emitted for the first time: next time we are about to emit that log, when we go to evaluate whether to call the underlying Handler, we will use the cached log level.

To see how this is problematic, start geth in dev mode with arbitrary vmodule and high verbosity: geth --dev --vmodule "accounts=12" --verbosity 5 console. In the console, set the global verbosity low. Log statements from the higher verbosities will still be emitted.

[MariusVanDerWijden]

Added a commit to address that. It just clears the cache on setting the verbosity which will force a recalculation