Provide build type in version.h

[carlescufi]

We need a 2-bit identifier of the build type:

• Production release
• Release candidate
• Development build

So we can propagate that up via HCI to the Host

[carlescufi]

Related to #1333

[nashif]

we have been using EXTRAVERSION for the rc, like we it right now for 1.9, development releases were set as 1.x.99

[carlescufi]

@nashif but that is not quite equivalent to a fully-fledged build type, in case the patch level goes > 99.

Otherwise I'm forced to do things like:

#if KERNEL_PATCHLEVEL == 99
..
#endif

Ideally we'd have something like:

KERNEL_BUILD_TYPE 0x01

[carlescufi]

@holtmann feel free to add your thoughts

[pfalcon]

in case the patch level goes > 99.

Not too late to change it to 999 ;-).

Otherwise I'm forced to do things like:
#if KERNEL_PATCHLEVEL == 99
..
#endif

I guess the talk is who'll be (not forgetting to) updating all these bits and pieces. Otherwise, we can have

#if KERNEL_PATCHLEVEL == 99
#define KERNEL_BUILD_TYPE KERNEL_BUILD_TYPE_DEVEL
#else  // checking EXTRAVERSION may be tricky, yeah
#endif

without need to introduce new knobs.

[carlescufi]

@pfalcon So my idea was to find that sorted out already in version.h, a macro that is part of kernel.h and that tells you which kind of build that is:

In kernel.h:

#define KERNEL_BUILD_DEV 0x00
#define KERNEL_BUILD_RC 0x01
#define KERNEL_BUILD_PROD 0x02

In version.h:

#define KERNEL_BUILD_TYPE KERNEL_BUILD_PROD

[nashif]

i am not saying the .99 solution is an ideal one, it is what we have an we need to find a better way for managing this.
We should also consider reserving a version header in the image that can be injected with versions and build-ids post-build as well.
Note that the version handling is going to change when we move to cmake, meaning it will be done using some other method, so I would wait and implement all of this in the context of cmake.