messages: Parse enum types

[robinkrahl]

With this patch, values for enum fields are automatically parsed into the corresponding enum types when using the message structs. If a value cannot be parsed correctly, it is added to a invalid_fields field so that users can manually parse that data if they want to.

[robinkrahl]

Updated:

• Dropped support for Vec<_> to keep things simple for the time being.
• Introduced the FromValue trait.

[stadelmanma]

I noticed you have some logic in there to convert the enum string/int value back into the "actual" type. Do you think we should keep the actual enum "instance" in the FitDataRecord instead of coercing them into strings/ints?

I'm not sure how exactly that would play out or if it could be implemented in a way that if someone was using them as an int/string the type conversion could happen automatically and not break existing code.

Relevant code in the profile/mod.rs file:

    // convert enum or rescale integer value into floating point
    if field_type.is_enum_type() {
        let val: i64 = value.try_into()?;
        if options.contains(&DecodeOption::ReturnNumericEnumValues) {
            Ok(Value::SInt64(val))
        } else if field_type.is_named_variant(val) {
            Ok(Value::String(get_field_variant_as_string(field_type, val)))
        } else {
            Ok(Value::SInt64(val))
        }
    } else {
        apply_scale_and_offset(value, scale, offset)
    }

[robinkrahl]

Do you think we should keep the actual enum "instance" in the FitDataRecord instead of coercing them into strings/ints?

It would make sense, but it’s not a requirement for me.

I'm not sure how exactly that would play out or if it could be implemented in a way that if someone was using them as an int/string the type conversion could happen automatically and not break existing code.

I think it is hard not to break existing code with such a change. I would consider it sufficient (and easy) to provide a simple workaround like a conversion function.