Its been my experience that the BLE support in ESP-IDF exposes the underlying BLE protocol. What this means is that one must perform study on "abstract" BLE and only then will the ESP-IDF BLE API start to fall into place. For example, with respect to BLE advertising ...
https://blog.bluetooth.com/bluetooth-lo ... dvertising
http://www.argenox.com/a-ble-advertising-primer/
I'll stick my neck out and say that one must be quite familiar with "Generic Access Profile" (GAP). This is the section of the overall specification that owns advertising. For example, and quoting from the first link:
ADV_IND
Known as Advertising Indications (ADV_IND), where a peripheral device requests connection to any central device (i.e., not directed at a particular central device).
Example: A smart watch requesting connection to any central device.
ADV_DIRECT_IND
Similar to ADV_IND, yet the connection request is directed at a specific central device.
Example: A smart watch requesting connection to a specific central device.
ADV_NONCONN_IND
Non connectable devices, advertising information to any listening device.
Example: Beacons in museums defining proximity to specific exhibits.
ADV_SCAN_IND
Similar to ADV_NONCONN_IND, with the option additional information via scan responses.
Example: A warehouse pallet beacon allowing a central device to request additional information about the pallet.
And hopefully from there you can see that the BLE constants exposed by ESP-IDF are (mostly) maps through to the underlying BLE specification story.