samples: bluetooth: GATT large MTU/throughput example

[JordanYates]

Is your enhancement proposal related to a problem? Please describe.
There are currently no in-tree examples of the Kconfig options and code flow required to setup a GATT connection to use a larger MTU than the default.

Given the multiple Kconfig namespaces that these options cross, a single reference example would be appreciated.

An example of the confusions and open questions from #25561.
CONFIG_BT_ACL_RX_COUNT needs to be increased from its default value of 1. CONFIG_BT_CTLR_RX_BUFFERS, which sets the default value of CONFIG_BT_ACL_RX_COUNT should however not be incremented. Do CONFIG_BT_L2CAP_TX_MTU and CONFIG_BT_L2CAP_RX_MTU need to increased? One of these depends on CONFIG_BT_HCI_ACL_FLOW_CONTROL, which should not be enabled.

Describe the solution you'd like
A variant of the samples/bluetooth/central application that additionally increases the MTU of the connection to the largest values supported by the GATT client.

The proj.conf would contain the minimal configs necessary to achieve this.

Describe alternatives you've considered
Improved documentation under:
https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-dev.html
or
https://docs.zephyrproject.org/latest/reference/bluetooth/gatt.html
Would also be an alternative.

Additional context

The Nordic NCS repository has a GATT throughput example that does increase the MTU.
This example uses Nordics custom BT controller, which means the proj.conf is not valid for the combined controller/host builds that are the default for Zephyr.
https://github.com/nrfconnect/sdk-nrf/tree/master/samples/bluetooth/throughput

[JordanYates]

# Uncoded LE Data Packet Format:
#
# | Preamble | Access  |                           PDU (2 to 257 bytes)                         |   CRC   |
# |          | Address | LL Header |       Link Layer PDU (0 to 251 bytes)           |    MIC   |         |
# |          |         |           | L2CAP Header |      L2CAP PDU (0-247 bytes)     | Optional |         |
# |          |         |           |              |    ATT Header    |  ATT Payload  |          |         |
# |          |         |           |              | OpCode | Handle  |               |          |         |
# |  1 byte  | 4 bytes |  2 bytes  |   4 bytes    | 1 byte | 2 bytes | 0 - 244 bytes | 4 bytes  | 3 bytes |
#
# L2CAP can be larger than 247 bytes, but will be split across multiple LL packets as a result.
# ATT payloads can be larger than 244 bytes, but will be split across multiple LL packets as a result.
# 
#
# Kconfig Symbols:
#     CONFIG_BT_CTLR_DATA_LENGTH_MAX : Maximum payload size of the Link Layer PDU
#     CONFIG_BT_BUF_ACL_TX_SIZE      : Maximum L2CAP PDU is limited to this value - 4
#     CONFIG_BT_BUF_ACL_RX_SIZE      : Maximum L2CAP PDU is limited to this value - 4
#     CONFIG_BT_L2CAP_TX_MTU         : Maximum L2CAP PDU size for transmission

In the meantime, here is documentation I made for others struggling with configuring this

[theob-pro]

Hi @JordanYates, do you think that the newly added sample is enough? We would like to get your feedback to know if we should improve it or if we could close this issue.

[JordanYates]

Looks to be enough, and if there are problems with it that should be its own issue.