feat(gfps_service): Update GFPS to support use of random addreses

[finger563]

Description

• Remove address change implementation from gfps_service, since it is not needed and may constrain application flexibility / design
• Update nearby_platform_GetBleAddress() to return the random address directly from NimBLE, for applications which support random addresses

Motivation and Context

In development of an application which utilizes address randomization, it was found that the current GFPS implementation failed. This update allows random addresses to work with GFPS.

How has this been tested?

Using address randomization code such as:

    ble_addr_t addr;
    int rc = 0;
    // generate a random address
    rc = ble_hs_id_gen_rnd(0, &addr);
    if (rc != 0) {
        logger_.error("Failed to generate random address");
        return false;
    }

    // make sure we set our address type
    NimBLEDevice::setOwnAddrType(BLE_OWN_ADDR_RANDOM, false);

    // set the address
    rc = ble_hs_id_set_rnd(addr.val);
    if (rc != 0) {
        logger_.error("Failed to set random address");
        return false;
    }

    // save the address to NVS
    espp::Nvs nvs;
    uint64_t random_address = 0;
    memcpy(&random_address, addr.val, 6);
    std::error_code ec;
    nvs.set_var("system", "random_address", random_address, ec);
    if (ec) {
        logger_.error("Failed to save random address to NVS");
        return false;
    }

    // now ensure it is set
    rc = ble_hs_util_ensure_addr(1);

Before entering pairing mode. Of course the address needs to be loaded from nvs before advertising for reconnection / after boot.

Also tested to ensure that if random addresses are not used, GFPS still works as well.

Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Hardware (schematic, board, system design) change
• Software change

Checklist:

• My change requires a change to the documentation.
• I have added / updated the documentation related to this change via either README or WIKI

Software

• I have added tests to cover my changes.
• I have updated the .github/workflows/build.yml file to add my new test to the automated cloud build github action.
• All new and existing tests passed.
• My code follows the code style of this project.

[github-actions]

✅Static analysis result - no issues found! ✅