RFCOMM: Refuse connection if max RFCOMM ports are used
Issue:
When max RFCOMM ports are used, the stack returns the current listening
port as new port while accepting the incoming RFCOMM connection.
This leads to an assert.
Steps to reproduce
==================
1. Connect DUT with RFCOMM clients until all 30 RFCOMM ports used.
(DUT using 17 ports for RFCOMM servers and 13 ports for clients)
3. Initiate SPP connection from remote to DUT
Bluetooth restarted due to assert in RFCOMM
Expected results: Incoming connection fails
Fix: Return null instead of current listening port when new port
creation fails
Test: Simulated scenario by reducing max rfc ports and tested
Bug:
147075796
Change-Id: I46cd8e6707575e9cb92670136c9d6e4b9988eb53