GAP，BT device name=248byte 重命名蓝牙设备为为最长字符串长度，另一台与其配对，可用设备蓝牙名称末尾显示特殊符号方块

修改MTK8766平台 BT device name=248byte时的传输问题

当蓝牙设备重命名至最大字符长度时，最后一位如果是字母，则没有这个问题。如果最后一位是汉字。则有可能转翻为“小方格”。将前面的字母删除一位，亦可正常显示。

这个Android原生的一个issue，在BT spec里，规定的device name长度最大为248byte，但在bt stack中，由于strlcpy和memcpy的读取方式有区别，所以实际上stack只能传递247byte，会把最后一个byte用‘0‘覆盖掉，这样就导致了显示name的异常，主要现象就是最后一个字符如果是汉字的话，要么显示不出来，要么显示为乱码（因为汉字编码占3byte，丢失1byte会导致解码异常），如果是英文或数字字符，则会丢失最后1byte。

patch1 (BD_NAME_LEN )——>(BD_NAME_LEN + 1)

（修复了name长度=248byte时，传输过程被memcpy和strlcpy函数截掉最后一个byte的问题，修复之前，name=248时，最后1byte无法正常传送，修复后，可以正常传输248byte的完整name）
这样，就解决最后一个字符如果是汉字的话，要么显示不出来，要么显示为乱码的问题。
——————————————————————————————————————————
**但是：发现新BUG： 当设备作为接受配对的一方时，由于authentication流程，会发起两次name request，对方也会回两次name response，但在接受方，第一次收到name response时，controller的LMP收到的name是完整的，而传递到HCI后中间的126个字节就变成了全0，导致上报的name只有前56个字节。

目前可以从两个方面来查：
1. 正面查name从LMP到HCI之间传递过程中为什么中间的字节被清零了——需要在收到name response的时候手动trigger coredump，在kernrl log中打印stp dump log，看driver收到的数据是否正常
2. 在stack里加判断条件，规避该问题——可以尝试添加附件的patch后再测试下
由于action 1查起来比较复杂，建议action 2，看是否能解决这一问题
关于这题能够达到的修改目标是：
1： 在发起扫描的时候，扫到的设备名称是短名——因为扫描时的name来源为对方设备的EIR包，EIR由于长度限制，会对name长度进行判断，一般是name不能超过50byte，超过的话会采用shorten name，就是只截取前50byte放在EIR中，所以扫描时显示在UI的name也就只有前50byte，能够在一行显示。
2：在发起配对的时候，会进行RNR，也就是去获取对方设备的完整name，这一过程中，配对发起方和配对接收方的流程有些差异：
2.1 :配对发起方：先发起RNR，再发起create connection，所以发起方在弹出配对框时，已经完成了RNR过程，显示的就是对方设备的完整名称，由于配对框大小限制，超出的就会用…表示
2.2 :配对接收方：先收到create connection，再发起RNR，并且由于收到了User confirmation request，所以会再发起一次RNR，所以会连着收到两个对端反馈的RNR response，正常来说这里收到的也是完整的name，但目前存在异常，收到的第一个RNR response中name的中间部分被0覆盖，所以上报的name不完整，导致显示在配对框中的也是不完整的name，所以不会有…的省略表示——需修复。
3:当完成了2中的RNR交互后，双方都拿到了对端的完整name，这时点击取消配对，toast显示的就会是完整的name
4:取消配对后，如果继续停留在扫描界面，就仍会继续扫描，如果没有扫到对方的EIR包，name就会保持显示完整name；如果扫到了，就会更新为EIR中的短name。

所以，目前还需要修复的问题，就是2中收到第一个RNR时name被0覆盖的问题。

（btif_config_get_str和cfg2prop的改动：修复了当设置了name=248byte后，重新关闭并打开蓝牙，写入的name会丢失最后1byte的问题，修复之前，重启蓝牙后name的最后1byte会被0覆盖，修复后，可以完整写入248byte的name）
该笔patch2 上半部分，达到的结果：
右边测试机向测试机发起配对。测试机配对框里面显示“shortened name”；辅助机配对框里面显示“name是带省略号”。

patch 2shorten name——>完整的name
在stack里加判断条件，规避该问题
配对接收方在RNR过程中上报了完整的name。所以在UI中就会显示成…省略的形式，而toast弹出的也是完整name。这样，之前提到的“收到第一个RNR时name被0覆盖的问题”已经fix。

Question:在每次发起和接收配对时，由”shortened name”变成“完整的name”，也就是问题2中说的name会“多行显示”。
A:这是正常的，之前有解释过，在扫描时，显示的是EIR中的name字段，EIR由于总长限制，会使用shorten name，所以显示的就是shorten name；发起配对后，会进行RNR，获取对方的完整name，并上报，所以UI就会更新为完整name