RFCOMM: Refuse connection if max RFCOMM ports are used

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