feat: client identification headers

[kwasniew]

About the changes

This PR adds standardised client identification headers to the feature and metrics calls that the client makes to Unleash. The headers are:

• x-unleash-appname: the name of the application that is using the client.
• x-unleash-connection-id: a unique identifier for the current instance of the client generated by the built-in UUID lib
• x-unleash-sdk: sdk information in the format unleash-client-android:<version>

All the headers are intended for the Unleash team so clients should not be affected.
The main use cases we have are:

• capacity planning by knowing the number of unique connections made to the backend API
• debugging misconfigured SDKs sending more traffic than expected

Important files

Discussion points

• it seems that instanceId is not exposed to users in this SDK so I can re-use it for connection id
• SDK version solved by enabling BuildConfig. I pass axion-release version to buildConfig.

In development the generated BuildConfig looks like this:

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String LIBRARY_PACKAGE_NAME = "io.getunleash.android";
  public static final String BUILD_TYPE = "debug";
  // Field from default config.
  public static final String VERSION = "1.2.3-client-identification-headers-SNAPSHOT";
}

The VERSION has a branch name and snapshot. I hope that after proper release it will get updated to a regular version.

[kwasniew]

will be deprecated after expand/contract period

[kwasniew]

we need to find a way to get current version instead of development

[kwasniew]

enable build config that auto generated BuildConfig file

[kwasniew]

add custom VERSION field to the BuildConfig

[gastonfournier]

it seems that instanceId is not exposed to users in this SDK so I can re-use it for connection id

This was an explicit decision during the design as instanceId should identify the instance and not be overridden. Maybe we should pursue this in all our SDKs.

The PR looks good!

[gastonfournier]

I hope we can deprecate UNLEASH-INSTANCEID header, as this connection id seems to be fulfilling the same purpose. We should open that conversation, but definitely outside of this PR scope

[sighphyre]

This was an explicit decision during the design as instanceId should identify the instance and not be overridden. Maybe we should pursue this in all our SDKs.

We did try, turns out that breaks Gitlab, which is why we rolled that back. We should still move in that direction though, agreed