RUM-1915: Add buildId property to the Error event schema

[0xnm]

This PR adds error.build_id property, which will contain unique build ID to be used to match with a mapping file (source map) for more precise symbolication, because different builds may have same version and relying on the version is not enough then.

[BenoitZugmeyer]

Is it different than build_version introduced in #160 ? Can it be collocated with it? (meaning: put build_id in CommonProperties next to build_version)

[0xnm]

@BenoitZugmeyer Yes, it is different. It is rather as versionCode on Android (which we don't sent yet, but probably we will), both version and build_version can be thought as marketing (shown to the user) and non-marketing (simple int) versions of the build set by the developer. While non-marketing version has to be unique for each app submission to the store (it is true for the AppStore and Play Store at least), it is possible to have different builds locally with same build_version.

The point of build_id though is to give unique UUID for each build made automatically, without the need for the developer to set it. It is a part of DataDog/dd-sdk-android-gradle-plugin#211 where we need to precisely match mapping file produced by the build with the error sent from the application.

[BenoitZugmeyer]

Thanks for the explanation. Maybe it's worth adding a bit more context in the field description.

Is there a reason to nest this field in @error? Could it be collocated with @build_version? Or, since FMU this is not user facing, maybe it could be added to @_dd.build_id?

[0xnm]

It is needed only for the symbolication process, to match stacktrace with symbols in the mapping file. And so since stacktrace is the property of error only, it is in the error level well, next to it, no need to pull it up to the common properties.

I've added a word that it is generated ID in the description.

[bcaudan]

I would also lean toward having this attribute at the same level than version or build_version.
For now, we only associate source code for error stack (and handling stack) but we could think of later collecting initiator stack for other events, for example to see from where in the source code a resource has been triggered.

[0xnm]

@bcaudan Thanks for the suggestion, it indeed makes sense keeping in mind the use-case you proposed. I pulled it up to the top level, in the common schema.

[andreicoj]

lgtm

[bcaudan]

LGTM