Bluetooth: ATT: MTU min instead of cap

The previous approach with `cap_eatt` was flawed. It would overwrite
`le_chan->tx.mtu`, losing its true value. (It is supposed to be the
L2CAP MTU as reported by the remote side.)

The previous approach worked out for UATT because the locally triggered
exchange always carries the remote MTU in the response, so we did not
need to keep track of the remote MTU.

But, unlike the UATT MTU exchange, the L2CAP reconfigure only exchanges
the MTU in one direction. If the remote does the first reconfigure, we
would correctly cap the ATT MTU to our local MTU. But, we would
incorrectly store this as the remote's MTU. When we then increase our
local MTU using `bt_eatt_reconfigure`, we correctly set and send our
MTU.  But we have an incorrect notion that the remote MTU is the value
that we ourselves limited. And mistake would incorrectly limit the
negotiated ATT MTU locally.

The simplest solution is to not mess with `le_chan->tx.mtu` and just
calculate the ATT MTU like Spec intended.

Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>