Refactored attribute limits to be controlled by the LoggerProvider

[evanlauer1]

Big Context

Logging Support is being added to hs-opentelemetry. Logging spec

Small (This PR) Context

LoggerProviders should control the AttributeLimits for Loggers. Previously, the entirety of LogAttributes was provided to the emitLogRecord function instead of passing the attributes via a HashMap Text AnyValue and AttributeLimits via a LoggerProvider accessed through the provided Logger. Relatedly, LogAttributes should be able to be changed after the creation of the Logger, but that will be added later.

Testing

• stack build runs

[evanlauer1]

• Added Simple LogRecordProcessor and refactored shutdown and forceFlush #136
• Added LogRecordExporters and updated documentation. #135
• Renamed Processor to SpanProcessor, Exporter to SpanExporter, and Logging to Logs #134
• Added LogProcessors and implemented shutdown and forceFlush for LoggerProviders #132
• Refactored LogRecords to be mutable so that attributes can be modified after creation #131
• Added Logging when creating spans or emitting logs drops attributes. Updated Severity Number #133
• Refactored attribute limits to be controlled by the LoggerProvider #129 👈
• Add LoggerProvider to create Loggers and allow registering a global LoggerProvider #128
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @evanlauer1 and the rest of your teammates on Graphite

[andrewsmith]

Is there anything about this that addresses the part of the spec that says this:

There SHOULD be a message printed in the SDK’s log to indicate to the user that an attribute was discarded due to such a limit. To prevent excessive logging, the message MUST be printed at most once per LogRecord (i.e., not per discarded attribute).

[iand675]

This is actually something that we don't support on the tracing side (which says effectively the same thing). I wanted to support it on the tracing side using OTel logging, so it's a bit of an ouroboros 😆

I think enough of the logging interface is in place that we should be be able to support this use case now though.

[evanlauer1]

This is addressed by the next downstream pull request in the stack. The change was to large to be reasonably contained in this PR.