Fix a bug in bluedroid when multiple SDP records are created (IDFGH-9219)

[AlbertWDev]

Definition of the bug fixed by this PR

When creating multiple SDP records using the esp_sdp_create_record() function, the first call raises the ESP_SDP_CREATE_RECORD_COMP_EVT event with an status of ESP_SDP_SUCCESS, as expected.
However, the following calls to register other SDP records generate events where the status and the handle parameters of the esp_sdp_cb_param_t->create_record struct have the same value, so the status is not considered a success and SDP records are not actually created, making it impossible to define more than one SDP record.
This happens because those values are set in the function bta_sdp_create_record(), where a tBTA_SDP union is declared and two of its possible values are written at the same time (status and handle).

For reference, this was the tBTA_SDP definition:

typedef union {
    tBTA_SDP_STATUS              status;            /* BTA_SDP_SEARCH_EVT */
    tBTA_SDP_SEARCH_COMP         sdp_search_comp;   /* BTA_SDP_SEARCH_COMP_EVT */
    int                          handle;
} tBTA_SDP;

And this is the relevant code of the bta_sdp_create_record() function where the status was overwritten:

void bta_sdp_create_record(tBTA_SDP_MSG *p_data)
{
    // [...]
    tBTA_SDP bta_sdp;
    bta_sdp.status = BTA_SDP_SUCCESS;
    bta_sdp.handle = (int)p_data->record.user_data;  // <-- Overwrites the 'bta_sdp.status' value
    // [...]
}

How the bug was fixed

This PR fixes this situation by creating a tBTA_SDP_CREATE_RECORD_USER struct with the two required values (mimicking the already defined tBTA_SDP_SEARCH_COMP struct), so setting the SDP record handle doesn't overwrite the status value.

[CLAassistant]

All committers have signed the CLA.

[xiongweichao]

Hi @AlbertWDev ,

Please rebase master.

Thanks

[AlbertWDev]

Hi @xiongweichao, I've just rebased master

[xiongweichao]

I think p_data->sdp_create_record.status is better than p_data->status here.

[AlbertWDev]

Thanks for the review! I totally agree, I was just mimicking the behaviour on the BTA_SDP_SEARCH_COMP_EVT, were p_data->status is used instead of p_data->sdp_search_comp.status. There should be no difference in terms of accessed memory, but I will update both to make the code clearer.

Edit: I just changed it (amended in the same commit to keep the commit history clean)