Add API to read Thread EUI-64

[kjbracey]

Description

Previously get_mac_address on a ThreadInterface returned the EUI-64
reported by the radio driver. This was required for commissioning, but
was inconsistent with other interfaces, and the API concept.

5.9.0 inadvertently changed this so that get_mac_address returned the
actual MAC address used by the radio, which is a hash result of the
EUI-64 for Thread.

The original "return the EUI-64" form was somewhat faulty, as
get_mac_address would not return the EUI-64 set by set_device_eui64() or
another mechanism before connect() was called.

Rather than revert to old behaviour, add a new API to get the device
EUI-64 to ThreadInterface, alongside the existing set API.

Pull request type

[X] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

New API, but required to get commissioning working properly in 5.9 due to an inadvertent (but desirable) behaviour change.

[JuhPuur]

Tested to work with mesh-minimal.

[0xc0170]

/morph build

[0xc0170]

Build will be restarted once rc3 completes (failed and have to be now restarted)

[mbed-ci]

Build : ABORTED

Build number : 2285
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7158/

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 2301
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7158/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1923
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7158/

[mbed-ci]

Test : SUCCESS

Build number : 2077
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7158/2077

[cmonr]

Pinging @ChiefBureaucraticOfficer. New API change = 5.10.0-rc1 release, but this is apparently needed for 5.9 release??

[cmonr]

Marking this as 5.10.0-rc1 since this is an API change.

[JuhPuur]

This is an API change, but it's a fix that restores functionality that was inadvertently removed in 5.9 and which is very much needed.
@cmonr I don't think we can wait on a API fix until 5.10.

[cmonr]

Interesting.

So if I understand correctly,

1. The original behavior was functionally correct, but did not comform to the API model.
2. The 5.9 update broke this so that the get_mac_address returns the mac address instead of the
   EUI-64.
3. This change corrects the function call, but now breaks comissioning.
   Q. How/why was this not caught in 5.9 OOB?
4. Instead of reverting the function to return the EUI-64 (which I agree with), this PR adds a new function call to read the EUI-64, maintaining the correct behavior with get_mac_address.

Assuming the above is all correct, I agree that this should go in ASAP.

@ARMmbed/mbed-os-maintainers @ChiefBureaucraticOfficer Thoughts?

[ghost]

I am ok with the changes as proposed. @bulislaw, do you have any thoughts on this one?

[adbridge]

In this particular instance I think we can be a bit flexible and allow this to go into a patch. However what is worrying me is we seem to be seeing an increasing number of items like this cropping up which should not be happening. This really needs to be the rare exception....

[bulislaw]

Works for me as well. But like @adbridge said we should be more careful about fixes to the APIs.

[kjbracey]

This was caught in OOB, but not in time to make it to 5.9.0. It was a known issue.

[kjbracey]

Actually, it didn't make it onto the mbed OS 5.9.0 known issues list, just the mbed mesh minimal example: ARMmbed/mbed-os-example-mesh-minimal#188 & ARMmbed/mbed-os-example-mesh-minimal#191