bluetooth: services: ras: Implement Ranging Responder role of RAS

[alexstanoev-nordic]

Implement the ranging responder (RRSP) server role of the Ranging Service draft specification.
This allows a ranging requestor (RREQ) to retrieve channel sounding ranging data from the local device.

This implementation contains support for all mandatory features, as well as using notifications for data transfer.

[NordicBuilder]

CI Information

^{To view the history of this post, clich the 'edited' button above}
Build number: 4

Inputs:

Sources:

more details

Github labels

Enabled	Name	Description
	ci-disabled	Disable the ci execution
	ci-all-test	Run all of ci, no test spec filtering will be done
	ci-force-downstream	Force execution of downstream even if twister fails
	ci-run-twister	Force run twister
	ci-run-zephyr-twister	Force run zephyr twister

List of changed files detected by CI (0)

Outputs:

Toolchain

Version:
Build docker image:

Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped; ⚠️ Quarantine

• ❌ Toolchain
• ❌ Build twister
• ❌ Integration tests

Note: This message is automatically posted and updated by the CI

[NordicBuilder]

You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds.

Note: This comment is automatically posted by the Documentation Publishing GitHub Action.

[olivier-le-sage]

Propose replacing BT_RAS_RRSP_MAX_STEPS_PER_PROCEDURE and BT_RAS_RRSP_MAX_STEPS_PER_PROCEDURE with:

• BT_RAS_RRSP_MAX_ANTENNA_PATHS (range 1 4 default 4)
• BT_RAS_RRSP_MODE_3_SUPPORTED (just yes/no, default yes)

then the only thing these configs do is change the value of BT_RAS_MAX_STEP_DATA_LEN.

We should also make sure there's some kind of warning in the case where the controller generates more data than expected

[alexstanoev-nordic]

I realised these configs are relevant for both RREQ and RRSP, so I reordered the Kconfig menus in the last commit as well.