Adding preprocessor checks before using DevelopmentCerts:kDac* constants

[sharadb-amazon]

Fixes #25388

Change summary

This change adds a necessary preprocessor check in src/credentials/examples/DeviceAttestationCredsExample.cpp to allow the code to build if CHIP_DEVICE_CONFIG_DEVICE_PRODUCT_ID is set to a value outside of the range of test values i.e. [0x8000, 0x801F]. (see src/credentials/examples/ExampleDACs.cpp) If we do not make this change, we end up with compilation failures like this when building an app (say the tv-casting-app) if the product id is outside the test range:

Undefined symbols for architecture arm64:
  "chip::DevelopmentCerts::kDacPublicKey", referenced from:
      chip::Credentials::Examples::(anonymous namespace)::ExampleDACProvider::SignWithDeviceAttestationKey(chip::Span<unsigned char const> const&, chip::Span<unsigned char>&) in libTvCastingCommon.a(libCredentials.DeviceAttestationCredsExample.cpp.o)
  "chip::DevelopmentCerts::kDacPrivateKey", referenced from:
      chip::Credentials::Examples::(anonymous namespace)::ExampleDACProvider::SignWithDeviceAttestationKey(chip::Span<unsigned char const> const&, chip::Span<unsigned char>&) in libTvCastingCommon.a(libCredentials.DeviceAttestationCredsExample.cpp.o)
  "chip::DevelopmentCerts::kDacCert", referenced from:
      chip::Credentials::Examples::(anonymous namespace)::ExampleDACProvider::GetDeviceAttestationCert(chip::Span<unsigned char>&) in libTvCastingCommon.a(libCredentials.DeviceAttestationCredsExample.cpp.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Testing

Successfully able to build the tv-casting-app with a CHIP_DEVICE_CONFIG_DEVICE_PRODUCT_ID set to a value outside the range of test values, like 0x7FFF.

[cliffamzn]

instead of hardcoding the 0x8000 here, can we define the CHIP_DEVICE_CONFIG_DEVICE_PRODUCT_ID_MIN/MAX or something in the ExampleDACs.h file?

It'd be nicer to have the control of the range specified close to where they're defined otherwise if we add additional product identifiers here you'd need to know to look at this spot too otherwise it won't work and you'd be wondering why

[Damian-Nordic]

Actually, wouldn't it be better to simply add a GN switch not to compile ExampleDACProvider if you use a non-default product ID? This class is only for test purposes so it shouldn't be used if you have your own DAC. Btw, why is the linker error occuring? Is ExampleDACProvider instantiated in your application? Wouldn't removing ExampleDACProvider from the application be enough to resolve it?

[sharadb-amazon]

Done, in this PR: #25953

Closing this one.

[andy31415]

It seems like this should be some GN compile flag deciding if example is compiled in or not. I.e. compilation should just not try to compile in instead of getting some link error.

[sharadb-amazon]

It seems like this should be some GN compile flag deciding if example is compiled in or not. I.e. compilation should just not try to compile in instead of getting some link error.

Done, in this PR: #25953

Closing this one.