Issue originating at metricbeat

• Version: 6.x, 7.x
• Operating System: Any
• Related issue: [Metricbeat] consumer_utilisation issue with RabbitMQ module in 7.0.0 #11833

schema/mapstriface conversion utility toInteger func returns:

• the integer if the conversion was possible
• a KeyNotFound error when the key is not present
• a generic error when the conversion fails

When using these conversion functions we will be considering an error a key that exist but whose value is nil, while some apps will report keys with empty values that should be treated as NotFound

Solution 1
turn this:

into this

	emptyIface, err := common.MapStr(data).GetValue(key)
	if err != nil || emptyIface == nil {
		return 0, schema.NewKeyNotFoundError(key)
	}

it is a very simple solution that should not modify any current usage of the int conversion, but it returns a KeyNotFound error when in fact the key might have been found, but the value is nil. The result is ok, the semantics are twisted.

Solution 2
Create an NilValueError that resembles KeyNotFound

this sounds like a much better solution, although looking at KeyNotFound implementation, this rings overcomplicated (is Optional and Required needed for an error object?). The reason for having these error fields is probably a scenario where a set of keys are being processed and all errors are being retrieved and classified upon their originating schema properties (Optional, Required), and these fields are "propagated" from the schema. If that's the case, I would suggest a refactor to decouple, simplify error management and make it more intuitive: errors are not optional or required, probably they fall into 2 categories: (real) errors or something to log at most. If that fits the logic of this conversion functions, those fields could be removed, and only real errors be returned.

For sure I'll be missing many scenarios here, I'm only proposing the 2 solutions above as starting points. Personally, I would go Solution 1 (although I don't like it) to solve current issues ASAP. Then think if creating a NilValueError is worth it, and if we should refactor or not