Do not stringify log messages in the browser console

[gzdunek]

Currently, all log messages from Connect are stringified with JSON.stringify to allow logging complex values like objects or arrays (instead of printing [object Object]). This happens for both file loggers and dev loggers in consoles.

The only downside of this is that reading long log messages (like unified resources response) is quite hard.
To improve readability, we can stop stringifying the values for the browser. Instead, we can use console.* functions to present objects or arrays in a nice, expandable way.

Before:

After:

Important

This only affects dev logs in the browser, not file or dev logs in a non-browser console (main process).

I also fixed a bug introduced in #39229, where pinnedOnly property started to be considered "sensitive". Instead of making partial matching on the key names, we can check the full name.

[ravicious]

The only thing that worries me is that there's no way to expand all collapsed objects at once. This means that:

1. You won't see the output as it comes, e.g. when the app continuously receives some kind of messages from tshd.
2. You won't be able to filter by parts of the output that have been collapsed.

The workaround for both of those things would be to simply look at the log file instead. Also, you can use Opt + click to recursively expand any given object, but that still works on only a single object.

I think we should be able to live with that, what do you think?

[gzdunek]

1. Correct, but if the response is more complex, looking for a particular part of it is hard when the message is unformatted.
2. I think I've never had a need to look for something in more than one response, so expanding it wouldn't be too much work.

Overall, your points are valid, but the pros still outweigh the cons to me.
You also provided a good workaround, so I think we don't loose anything here.

[public-teleport-github-review-bot]

@gzdunek See the table below for backport results.

Branch	Result
branch/v15	Create PR