Adding network information to logs

[LikeTheSalad]

Closes #140

This PR adds net.host.connection.type (and net.host.connection.subtype when available) to all log signals. These attr names arrive at ES as network.connection.type and network.connection.subtype respectively.

[felixbarny]

I was under the impression that we just wanted to add network information to errors and crashes, not all logs.

[LikeTheSalad]

Yes, we did mention that last week, though yesterday we decided to do so for all logs. If I remember correctly I think it was due to the fact that our users can send custom errors by sending logs with a "type=error" attribute (or something similar, I can't remember the exact attr right now), so if we added these extra attrs only to the crashes and errors that we create, then the custom errors would have the same filtering issue.

[felixbarny]

Oh, I see. When does this attribute visitor run? Could we check if the attributes contain type=error and only add the network info in that case?

[LikeTheSalad]

The visitor gets called every time a log is emitted so it is possible to adjust its behaviour later. There are a couple of issues with reading attrs from each log at this stage though. One is that our visitor currently only receives an instance of AttributesBuilder which doesn't allow reading from it, and the other one is that the log as we get it in the processor is of type ReadWriteLogRecord which also doesn't allow to read attrs from itself, although we could call a method it contains to transform it into a LogRecordData which is readable, though that process will happen again automatically when sending the log to the exporter, so I'm concerned about duplicating that work.

It would take more work to exclude some logs from having this info than adding it to all, it's not impossible though, we could do a little refactor and provide the existing attrs along with the AttributesVisitor which could enable us to add this logic, or we can even move the visitor to the exporter where we wouldn't have to repeat the work of converting the logs to a readable format. Though in the end what concerns me about this is that, since the UI has this general filter that always relies on the network type info to be available, how can we tell that a similar issue won't arise in the future if we decide to exclude some logs from having it?