example: Optimized parts of the code in the gatt_server_service_table example. (IDFGH-11491)

[TritiumXs]

I found some redundancy in certain parts of the code, so I made modifications by removing redundant segments. These changes do not affect the functionality of the code.

[github-actions]

	Messages
📖	Good Job! All checks are passing!

---

👋 Welcome TritiumXs, 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 1861fbc

[esp-zhp]

Thank you for your feedback. The reason for writing it this way is primarily to emphasize the independence of the contents of adv_data and scan_rsp_data, aiming to prevent any potential misunderstanding on the part of the users.

[TritiumXs]

Thank you for your feedback. The reason for writing it this way is primarily to emphasize the independence of the contents of adv_data and scan_rsp_data, aiming to prevent any potential misunderstanding on the part of the users.

Okay, but the explanation for "scan_rsp_data.p_service_data" isn't the same as for "adv_data." This is a minor detail, but if this issue can be corrected, I believe it can be improved.

[esp-zhp]

Yes, we will further improve this area in the future. Do you find any other parts of the documentation unclear? We would greatly appreciate your feedback.

[TritiumXs]

Yes, we will further improve this area in the future. Do you find any other parts of the documentation unclear? We would greatly appreciate your feedback.

Oh, indeed, there are some suggestions. UUIDs are really hard to remember. I think we can define a macro, allowing users to initialize using this macro and then modify it according to their needs. Also, the explanation for "raw_adv_data" in this example isn't very clear and may not be very friendly for developers new to BLE. I hope it can be supplemented more comprehensively.

[esp-zhp]

Alright, I will explain the format of raw_scan_rsp_data in the document later to make it easier for beginners to understand.

[TritiumXs]

Alright, I will explain the format of raw_scan_rsp_data in the document later to make it easier for beginners to understand.

And I found that the macro for "appearance" has already been defined, but it hasn't been used in the example.