config: proposal: Do not use pointers in model

[pellared]

I find having pointers in domain models not clean.

From the usage perspective it often leads to creating helpers like ptrInt, ptrString (related Go proposal golang/go#45624)

We could use (and define) something like this instead of using pointers:

package schema

type Optional[T any] struct {
  value T
  empty bool
}

func OptionalValue[T any](T v) {
  return Optional{value: v}
}

func OptionalEmpty[T any](T v) {
  return Optional{empty: true}
}

func (o Optional[T]) Empty() bool {
  return o.empty
}

func (o Optional[T]) Value() T {
  if o.empty {
    panic("empty value")
  }
  return o.value
}

func (o Optional[T]) ValueOrDefault(dft T) T {
  if o.empty {
    return dft
  }
  return o.value
}

I think if we could use such generic type then the code would be more readable and maintainable. Also using such code should be safer as writing a nil deference panic would be harder. Moreover, if the average case is to pass the config model around a single call stack, non pointer is probably better performance-wise.

On the other hand using such generic would require more code if e.g. the user would like to log the config model value.

Based on discussion in #4228 (comment)

[pellared]

More drawbacks:

1. It does not feel idiomatic in go to use such generics. Also @MadVikingGod pointed out that shouldn't make a helper type just to avoid some helper functions. The proposal: expression to create pointer to simple types golang/go#45624 should address the issue
2. How we would using pointers is easier if one would like to e.g. not create a meter provider

cfg, err := configyaml.Parse(file)
// err handling
cfg.Metrics = nil // do not create a meter provider
sdk, err := config.NewSDK(cfg)

3. Usually the config would be created by parsing configuration files. We do not expect OTel users to create them by hand (the config model should easily created by the parser modules).

Closing as I also changed my mind regarding my proposal.

CC @codeboten