Bluetooth: Mesh: Move dfu mbt models into their own elements

[m-alperen-sener]

• Tests: Bluetooth: Tester: Mesh DFUM and BLOB should have own elements
  Moving the blob client, dfd server and dfu server to their own elements and increasing the CONFIG_BT_MESH_TX_SEG_MAX to 8 to fit new composition data into composition data page status message.
  Standalone mesh blob client and DFU distributor/update server models requires one element and those elements only contain the main models and the models they extend to.
  Referring to MshMBT_v1.0 Section 6.1: The BLOB Transfer Client model defines the messages listed in Table 6.1 , and requires one element: the BLOB Transfer Client Main element. The BLOB Transfer Client Main element contains the BLOB Transfer Client main model.
  And referring to MshDFU_v1.0 Sections 6.1.1 and 6.2.1:
  6.1.1
  The Firmware Update Server model adds the state instances listed in Table 6.1 and Table 6.2 and the messages listed in Table 6.3 to the model it extends, and requires one element: the Firmware Update Main element. The Firmware Update Main element contains the Firmware Update Server main model and all the models that the main model extends.
  6.2.1
  The Firmware Distribution Server model adds the state instances listed in Table 6.7 and Table 6.8 and the messages listed in Table 6.9 to the model it extends, and requires one element: the Firmware Distribution Main element. The Firmware Distribution Main element contains the Firmware Distribution Server main model and all the models that the main model extends.

• Bluetooth: Mesh: Check that required models exists on the same element
  Referring to MshDFU_v1.0 Sections 6.1.1, 6.2.1 and 7.1.1 model descriptions: DFU/DFD server/clients extend BLOB Transfer root models and DFD server requires Firmware Update Client on the same element. For this reason we need to make sure that those main models or root models exist on the same element. And also firmware update client can not be forced to be in the first element.

• For all model extention call return the error code in case of an error.

[omkar3141]

Looks fine to me, of course there are some old naming conventions issues, but it is up to you if you want to fix it.

[alxelax]

LGTM at the moment. When you satisfy the Compliance checker, I'll approve it.

[PavelVPV]

@sjanc, could you please look at this PR?

[m-alperen-sener]

Tried to shorten error log messages without losing explanation for what the actual problem is. The key point is "not being on the same element", just saying "missing" might not give the message, or puzzle people. I am OK with removing all err logs anyway 👍

[omkar3141]

Tried to shorten error log messages without losing explanation for what the actual problem is. The key point is "not being on the same element", just saying "missing" might not give the message, or puzzle people. I am OK with removing all err logs anyway 👍

It is not necessary at all. If there is a problem, the log messages anyway print files names, etc. Even if MINIMAL is enabled, simply searching by string globally one can easily locate the log strings in code base. I feel, we shouldn't treat log messages as a way to educate users about what is the right thing to do. Instead, use them to actually print error codes or some useful information. This keeps application footprint low at development stage itself.

[omkar3141]

Thanks. Looks good to me.

[kartben]

@sjanc PTAL