BT Classic: support for 32 and 128-bit custom UUIDs (IDFGH-10721)

[ilutchenko]

The problem

This PR fixes issue #11529

What was done

I added new API functions that can add 32 and 128-bit UUID to the EIR data when these UUIDs are set in SDP.
The old functions that only work with 16-bit UUIDs have been left unchanged to avoid having to redo code that already utilizes them.

How it was tested

sdptool and wireshark output:
for 32-bit UUID:

for 128-bit UUID:

[CLAassistant]

All committers have signed the CLA.

[xiongweichao]

Please delete unnecessary whitespace in the code.

[ESP-YTGerd]

Hi, @ilutchenko thanks for your contribution, are you still following up this PR? Please resolve all the comments so that we can merge it.

[ilutchenko]

Hi @ESP-YTGerd ! Yes, I will fix up it soon. Just found some bugs during applying @xiongweichao's suggestions, need to figure out how to deal with them in the best way.

[github-actions]

	Messages
📖	Good Job! All checks are passing!

---

👋 Welcome ilutchenko, thank you for your first contribution to espressif/esp-idf project!

📘 Please check Contributions Guide for the contribution checklist, information regarding code and documentation style, testing and other topics.

🖊️ Please also make sure you have read and signed the Contributor License Agreement for espressif/esp-idf project.

Pull request review and merge process you can expect

Espressif develops the ESP-IDF project in an internal repository (Gitlab). We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

1. An internal issue has been created for the PR, we assign it to the relevant engineer
2. They review the PR and either approve it or ask you for changes or clarifications
3. Once the Github PR is approved, we synchronize it into our internal git repository
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing
   • At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the master branch
6. On next sync from the internal git repository merged change will appear in this public Github repository

---

Generated by 🚫 dangerJS against 0a23da7

[ilutchenko]

So, deleting records and EIR UUIDs pulled me into a deep rabbit hole.
As I discovered, SDP records creation and removal didn't work correctly.
So I spent some time debugging and bugfixing.

Done since the previous PR version:

• resolved xiongweichao's comments
• fixed handler return when SDP record is created
• fixed SDP database slot release in free_sdp_slot()
• UUID is removed from EIR when you delete the SDP record with esp_sdp_remove_record()

@xiongweichao , could you take another look at this PR, please?

[ilutchenko]

@xiongweichao , @ESP-YTGerd
Could you take a last look at this PR, please?

BTW, I have a question about failed CI. Pre-commit check passed successfully on my local machine but failed on GitHub Actions with a strange error.
Should I do something with it?

[ESP-YTGerd]

Hi, @ilutchenko
1: Can try to rebase to the Origin/Master branch, since the pre-commit just check the codes what you have committed.
2: It's also recommended to modify the commit message, which has the following format:

Subject (first line) has format: <type|action>(<scope/component>): <summary> (or <type|action>: <summary>)
If related to Github issue, add **full** Github issue link, e.g. `https://github.com/espressif/esp-idf/issues/47`

Example of a complete commit message:

feat(bt/bluedroid): Add new APIs for 32 and 128-bit UUIDs

1: <detail >(if needed)

Closes https://github.com/espressif/esp-idf/issues/xxx (if github issue linked)

Explanation of typical <action/type> in conventional commit style:

* `change`: making general changes or improvements to the codebase (e.g.: `change(api): Style of authentication module`)
* `ci`: making changes to the CI system configuration or CI scripts (e.g.: `ci: Configure pre-commit checks`)
* `docs`: making changes to the documentation (e.g.: `docs(ble): Update BLE API documentation`)
* `feat`: adding a new feature or functionality to the project (e.g: `feat(api): Implement user login functionality`)
* `fix`: fixing a bug or resolving an issue (e.g: `fix(mbedtls): Fix null pointer exception in data validation`)
* `refactor`: refactoring existing code without changing its behavior (e.g: `refactor(area): Extract common utility function`)
* `remove`: removing files, features, or functionalities from the project (e.g: `remove(api): Delete deprecated API endpoint`)
* `revert`: reverting a previous change (e.g: `revert(api): Revert changes to user authentication from MR 12345`)

[ilutchenko]

Hi @ESP-YTGerd
So, I squashed all the work into one commit and updated its description as you suggested.
I think it is ready to merge.

[ESP-YTGerd]

Hi, @ilutchenko
LGTM, but also please resolve the comments what I have reviewed and then I can merge this PR, thanks!

[ilutchenko]

Hi @ESP-YTGerd ,
All notes were implemented and comments sections were resolved.

[ESP-YTGerd]

Suggested change

	void BTM_AddCustomEirService( tBT_UUID *custom_uuid, tBT_UUID uuid );
	void BTM_AddCustomEirService(tBT_UUID *custom_uuid, tBT_UUID uuid);

[ilutchenko]

Hmm, some other function declarations in this file have spaces near bracers, and some don't.
Okay, I removed them.

[ESP-YTGerd]

@ilutchenko
oh, sorry, my bad, I forgot to submit my comments.

[ilutchenko]

@ESP-YTGerd , done

[ESP-YTGerd]

Hi, @ilutchenko The internal MR in gitlab was created and all the changes will be automatically synchronized to github, once the MR is merged.

[ESP-YTGerd]

Hi, @ilutchenko
This PR has been merged and thanks for your contribution again.