Fix xwalk BT extension for bluez5(Tizen common 3.0)

[ciscoaphao]

During integration of xwalk on tizen 3.0, the BT adapter was not responding and crashes each time the adapter is powered on (after dbus replies)
After comparison with bluez4 porting, it seems there are missing callbacks.

How to test: On the Tizen device:
// Activate BT radio

connmanctl enable bluetooth
// bt_use is the only group to have BT policies (/etc/dbus-1/system.d/bluetooth.conf)
usermod -A bt_use guest

Launch/deploy a Web application calling BT APIs for guest user. (e.g. Settings.wgt)
(expected:
Adapter should display name "BlueZ 5.19" and scanning should work.)

[crosswalk-trybot]

Testing patch series with ciscoaphao/tizen-extensions-crosswalk@bf23247 as its head.

Bot	Status
tizen-extensions-crosswalk Common	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/tizen-extensions-crosswalk Common/builds/625)

[rakuco]

Can you explain why this part is necessary?

[rakuco]

Thanks for the patch. I'm not entirely familiar with this code, so my only question after looking at the bluez4 version is whether you don't need to initialize all_pending_ in the bluez5 one: the former seems to manipulate it in several places, whereas the latter does not use it at all.

[ciscoaphao]

Hi,

1. Yes you are right, the initialization of all_pending_ is safer.
   all_pending_ = NULL;
   (Because I dont know if introducing the list<GCancellable*> would add some mem leakage of
   other behavior; all_pending at NULL will keep most of the current behavior)

2. bluez4 manipulates this field in several places.

I only noticed in my bluez5 testing a crash in that initialization for the moment.
Once surrounded devices are scanned, there is not problem.
(crash due to unwrap by G_CALLBACK_CANCELLABLE_1 of formerly passed this pointer
which does not contains a cancellable pointer or wrong reference)

But you are right, most often there is a callback for the interface and the macro G_CALLBACK_CANCELLABLE_1, required a wrapped CancellableWrap()
in order to retrieve contextCancellable.
Maybe thoses fields should be extended to the 3 other calls in bluez5 porting. Like you, I
discover that code too.

3. For identify_bluetooth_type.sh script: the former person implements a priority on capi-network-bluetooth package detection which has for consequence the non compilation of Bluetooth_instance_bluez5.c
   on a platform that has both bluez/capi_network-bluetooth packages, this makes the Tizen/BT API tizen.bluetooth.adapter() and others never work (because compiling/linking capi instead of bluez implementation)

4. If you need to debug the Bluetooth dbus:
   Create with that content: /etc/dbus-1/system-local.conf

Reboot the STB and run as root:
dbus-monitor --system

[ciscoaphao]

There are 2 Tizen/BT html demos

1. located at tizen-extensions-crosswalk/demos/tizen/bluetooth.html
   But it has not been maintained and is missing "tizen-web-ui-fw" javascript to be pushed in the Tizen device's /usr/share
   (See /bluetooth.html including the scripts src="file:///usr/share/tizen-web-ui-fw/ .....)

2. the other one is in the examples (more complete)
   ( tizen-extensions-crosswalk/examples/bluetooth.html )
   /usr/bin/xwalkctl -d 9222;xwalk-launcher file:///usr/share/tizen-extensions-crosswalk/examples/bluetooth.html -d
   (which seems to test more BT features)

By launching examples/bluetooth.html, some APIs are missing for bluez5 (setName(), setPowered()
libtizen_bluetooth.so: undefined symbol: _ZN17BluetoothInstance24HandleSetAdapterPropertyERKN8picojson5valueE )

[rakuco]

3. For identify_bluetooth_type.sh script: the former person implements a priority on capi-network-bluetooth package detection which has for consequence the non compilation of Bluetooth_instance_bluez5.c
   on a platform that has both bluez/capi_network-bluetooth packages, this makes the Tizen/BT API tizen.bluetooth.adapter() and others never work (because compiling/linking capi instead of bluez implementation)

@baleboy and @poussa can probably help me here since my memory of all this is blurry.

As I recall, the "official" way of using the Bluetooth APIs in Tizen 3.0 (at least which we were testing at the time) was through Tizen's C API code, which is why identify_bluetooth_type.sh was giving preference to it.

The change you've made reverses this check. It's not wrong, but I'm also not sure this is the design we want to follow (Francesco and Sakari can provide more information).

Is the objective here just to build the BlueZ code? In that case, does passing -Dbluetooth=bluez5 to gyp also work?