log: Change EnabledParameters to have a field instead of getter and setter

[pellared]

What

Allow users to to write less verbose code by changing methods to field so that the callers can do:

if logger.Enabled(ctx, log.EnabledParameters{ Severity: log.SeverityDebug }) {
 // ...
}

instead of

params := log.EnabledParameters{}
params.SetSeverity(log.SeverityDebug)
if logger.Enabled(ctx, params) {
 // ...
}

Why

• We may provide a Logger.EnabledEvent user-facing API in close future and it would be nice if the signatures are similar. See: Add Event Enabled operation to Logger opentelemetry-specification#4263. The possible alternative is that user-facing Logger.Enabled would also be used for events as well.

• There is a chance that the Logger API is going to be user-facing. See: Define whether instrumentations can emit non-event log records opentelemetry-specification#4234.

• I (subjectively) believe that having a shorter type name and using fields instead of methods has a better user experience.
  Ideally the user would prefer having Enabled(ctx context.Context, severity SeverityLevel) bool.
  However, we would be not able to provide additional parameters without creating new methods.

• I was thinking for for a few weeks before proposing this PR. I was worried if fields would be able to handle all possible cases. However, we can always add methods for future parameters. Having mixed fields and methods should not be the end of the world - especially that it is e.g. how slog.Record is designed. We were discussing inside Logs SIG if we ever would like to add (partial) attributes or (partial) body to Logger.Enabled. We all agreed that we do not want it as it can introduce overhead that we want to avoid and also it can lead to a very confusing API experience. Moreover, event name is being promoted to a top-level field of a log record - this was the only "attribute" that seem to be important, but there are even more reasons to promote it to a top-level field. See: Add EventName to Log and Event Record in data model opentelemetry-specification#4260. Therefore, there is a pretty low chance that we will introduce any complex parameter in future.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.1%. Comparing base (9f82e51) to head (581ea29).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #6009   +/-   ##
=====================================
  Coverage   82.1%   82.1%           
=====================================
  Files        273     273           
  Lines      23648   23643    -5     
=====================================
- Hits       19433   19432    -1     
+ Misses      3870    3866    -4     
  Partials     345     345           

see 2 files with indirect coverage changes

[dashpole]

Do we have any other examples of FooParameters or FooParams? Consistency across the codebase is important to me

[MrAlias]

https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#SamplingParameters

[pellared]

Do we have any other examples of FooParameters or FooParams? Consistency across the codebase is important to me

Renaming back so this PR would only propose to have fields instead of getters and setters.

[pellared]

@dashpole, @MrAlias, renamed back to EnabledParameters.

There is need to rush with this PR. We can discuss it during SIG meeting.

[dashpole]

I'm definitely ok with this. Having a struct for sampling has worked well so far, and this seems similar.