Support "unlimited" limit values

[MrAlias]

Span limit value can be "unlimited". This concept is not currently supported in the SpanLimits

opentelemetry-go/sdk/trace/config.go

Lines 35 to 51 in 065ba75

	func (sl *SpanLimits) ensureDefault() {
	if sl.EventCountLimit <= 0 {
	sl.EventCountLimit = DefaultEventCountLimit
	}
	if sl.AttributeCountLimit <= 0 {
	sl.AttributeCountLimit = DefaultAttributeCountLimit
	}
	if sl.LinkCountLimit <= 0 {
	sl.LinkCountLimit = DefaultLinkCountLimit
	}
	if sl.AttributePerEventCountLimit <= 0 {
	sl.AttributePerEventCountLimit = DefaultAttributePerEventCountLimit
	}
	if sl.AttributePerLinkCountLimit <= 0 {
	sl.AttributePerLinkCountLimit = DefaultAttributePerLinkCountLimit
	}
	}

Proposal

Accept negative values as being infinite.

This seems to be a common approach in other Go code, and is a stated reason many types use int instead of uint.

Recognized issues with approach

• The environment variable values are invalid if negative and would need to be translated. Given invalid values would be treated as unset values and use the default, this does not pose a real issue.
• This will be a change in current behavior. This behavior, using default values if negative, is undocumented. Changing and documenting the new approach will not change the API.

Alternatives

Use math.MaxInt.

• This would not be the same as infinite as there would be no way to determine if "no limit" should be applied or the maximal limit. This would be a rare situation.
• This would be a unique way to define infinite. I do not know any other code that does this.

[MrAlias]

It also seems like 0 needs to be a supported value. It is stated as a supported value for the OpenTelemetry specification.

If we were to support accepting these values, using the WithSpanLimits option to pass partial SpanLimits would be problematic. The unset values would default to 0, now a valid value. It seems like adding a func DefaultSpanLimits() SpanLimits function that returns a SpanLimits struct with the defaults already applied to all fields would be useful.

[Aneurysm9]

• The environment variable values are invalid if negative and would need to be translated. Given invalid values would be treated as unset values and use the default, this does not pose a real issue.

I'm not sure I follow here. Are values received from environment variables not strings that would need to be converted to integers with strconv.Atoi()? That should handle negative values just fine.

[MrAlias]

I'm not sure I follow here. Are values received from environment variables not strings that would need to be converted to integers with strconv.Atoi()? That should handle negative values just fine.

Right, but the specification considers negative values for environment variables as invalid.