Clarify parse requirements around null vs. empty

[jack-berg]

The file config spec says:

Parse MUST interpret null as equivalent to unset.

This has led to some confusion (see discussion 1) and could use clarification.

Let's illustrate the intent of this statement with some examples:

Example 1

meter_provider:
  views:
    - selector:
         name: my-metric1
      stream:
        aggregation:
          drop:
    - selector:
         name: my-metric2
      stream:
        aggregation:
          explicit_bucket_histogram:
            boundaries: [1.0, 5.0, 10.0]

Views have an option to configure the aggregation of the resulting metric stream. Some aggregations like explicit_bucket_histogram accept some configurable parameters. Others like drop do not. We want users to be able to use the syntax above, and not have to specify drop: {}.

When the YAML above is parsed, drop: resolves to null, while drop:{} resolves to an empty object. We need the fact that the drop key was provided to be retained after parse. In other words, it would not be acceptable if key/values with a null value were dropped by parse. It is semantically meaningful that a key was set, even if its value is null.

Example 2

attribute_limits:
  # Configure max attribute value size.
  attribute_value_length_limit: ${OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT}

The attribute_value_length_limit has no default value. If unset, no limit should be imposed on the length of attribute values. In this snippet, we reference the OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT env var using the env var substitution syntax. If the env var is unset, we want ensure the resulting SDK is created with no length limit. The result should be equivalent if the the .attribute_limits.attribute_value_length_limit is omitted altogether.

We should clarify the spec to ensure that the behavior in these examples is accomplished.