Bluetooth: Controller: llcp: Wrong effective time calculation if PHY changed

[ppryga-nordic]

Describe the bug
If there is a PHY change on a connection it may happen that effective
RX and TX time changes also. That change is applied after an instant.

Implemented handling of effective time calculation is based on the
maximum PDU length, new PHY and local (default) maximum TX or RX time.

The maximum TX value is set to default one that corresponds to PHY 1M
during the Controller initialization. It can be updated by host to other
value. By default Zephyr Host updates it to max possible TX time for all
supported PHYs. If PHY CODED is enabled, it is the longest possible TX
duration 17040 us.

The maximum RX value is set to default during connection creation.
In case of use of legacy advertising, the value is also related with
PHY 1M. It can be updated by data length extension procedure.

If the maximum RX value is set to some value and there is a change
of a PHY to one that requires more time to send a PDU with the same
length, then the maximum RX value is wrongly calculated.

Function pu_calc_eff_time returns a value that is the default_time
argument. The problem is that the default_time should be adjusted
to new maximum RX time required for a new PHY.

To solve that there should be an evaluation of a new maximum RX and
TX time based on new PHY.

The problem occurred in DF tests that check collision mitigation
between PHY update control procedure and CTE request control procedure.

There was missing CONFIG_BT_CTLR_PHY_CODED option in CTE request
unit tests. The code was working because the ULL implementation of
PHY change control procedure does not verify if PHY CODED is supported.

When missing support was enabled, tests showed wrong evaluation of
maximum RX time.

Expected behavior
The effective RX and TX time is calculated correctly.
All unit tests pass.

Impact
Medium, relates with refactored LLCPs only.