Option to filter logs by priority

[philips77]

This PR fixes #346.
The new method

Android-BLE-Library/ble/src/main/java/no/nordicsemi/android/ble/utils/ILogger.java

Lines 32 to 37 in e55d46b

	/**
	* Returns the minimum log priority that should be logged.
	* @return Minimum log priority.
	* @since 2.4.0
	*/
	@LogPriority int getMinLogPriority();

in BleManager and BleServerManager allows to omit creating and logging logs on lower priorities. By default, logs from levels Log.INFO and higher will be logged, which is a change in default behavior. Previously all logs were produced, even if later ignored.
To disable logging, return Log.ERROR or Log.ASSERT from those methods. To restore previous behavior, return Log.VERBOSE.

[x2764tech]

Thanks for all this work @philips77

Have you memory profiled this?

My fear is that, although this allows log filtering, it doesn't necessarily prevent the issue of object allocation.

---

My understanding of how lambdas work in Java is that each lambda potentially allocates a new object that captures the closure information.
So, log(Log.INFO, () -> "Hello") is roughly equivalent to log(Log.INFO, new Loggable() { String log() { return "Hello"; } }).
Which means an object allocation even when the log level is disabled.
Of course, the runtime implementation may be able in inline some or all of this, but this has the potential to vary from phone to phone, and android version to android version.

Unfortunately, the only way I've successfully implemented memory efficient log filtering is by using if statements at the site of logging.
so log(Log.INFO, "Hello " + state) becomes if(isLogLevelEnabled(Log.INFO)) { log(Log.INFO, "Hello " + state) }.
It's tempting to use language features to eliminate this, as you have done, but, as I've shown above, this doesn't really solve the problem of object allocation when a log level isn't enabled.

[philips77]

I precisely wanted to

to use language features to eliminate this

as it was tempting. However, it's still way faster than before. I ca refactor it once again to add tons of ifs :(

[x2764tech]

@philips77 are you able to memory profile this before doing all that work?
On Android 11, I'm seeing lots of memory churn because of the allocations for Strings for logging in notifications.

[philips77]

Hello,

Allocating objects for lambdas should still be much better than the previous solution. I'll leave the current implementation for now, as we're thinking about redoing this project in Kotlin anyway. I'll add some more features, check reported issues and will release it as 2.4.