Check return of BlockDevice::init() in TDBStore.

[SeppoTakalo]

Description

Return value was ignored, and TDBStore:init() ended up in a
MBED_ERROR() phase after that.

TDBStore API was limited to allow returning of only two separate
errors, which may end up hiding the actual return value. Change
the documentation slightly to allow returning of original error
code from the underlying block device.

Fixes #11591

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[x] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@VeijoPesonen

Release Notes

TDBSTore::init() is now allowed to return error codes from underlying BlockeDevice.
Previously the API was limited to return only MBED_ERROR_READ_FAILED or MBED_ERROR_WRITE_FAILED which might have hidden the actual error code from the device.
Now application will get the original return value passed from BlockDevice.

[VeijoPesonen]

Looks good to me.

[0xc0170]

Astyle shows one error , otherwise looks fine

[SeppoTakalo]

Astyle should be fixed now.

[ciarmcom]

@SeppoTakalo, thank you for your changes.
@VeijoPesonen @ARMmbed/mbed-os-storage @ARMmbed/mbed-os-maintainers please review.

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

[pauluap]

In resolving a problem I had with this issue (#11591), there are two possible problems with this approach:

1. There already is a fail label in the file, at line 502. I'm not up on my goto skills, but I am surprised that the file compiles with two identical labels in different places. I had thought that goto labels only has file scope, so I'm uncertain that the behavior will be restricted to function scope and calling goto fail would work in both TDBStore::set_start and TDBStore::init
2. There are many functions in the public interface that do not check if the instance has been initialized (there are some that do, however), and calling those would lead to badness. In the ticket referenced above, I have made changes to those functions.

[VeijoPesonen]

I'm not up on my goto skills, but I am surprised that the file compiles with two identical labels in different places. I had thought that goto labels only has file scope, so I'm uncertain that the behavior will be restricted to function scope and calling goto fail would work in both TDBStore::set_start and TDBStore::init

Chapter 6.1 Labeled statement - Programming Languages — C++:

The only use of an identifier label is as the target of a goto. The scope of a label is the function in which it appears. Labels shall not be redeclared within a function. A label can be used in a goto statement before its definition. Labels have their own name space and do not interfere with other identifiers.

[SeppoTakalo]

Using API that returns failure after init() call might lead to badness, which is a failure on the application, not the API.

Protective programming would allow applications to misbehave without crashing, which leads to errors being ignored, because its "up and running" in the testing phase. So crashing is what I wan't.

[SeppoTakalo]

@0xc0170 Ping, this is reviewed and already passed the tests.

[0xc0170]

I wonder why reinterpret cast is needed but its all over the file for these handles