ExhaustibleBlockDevice: revert commit 10481f2

[VeijoPesonen]

Fixes #12832. Reverts commit 10481f2 partially.
Changes made to ExhaustibleBlockDevice hides simulated flash degradation
which is the assumed behavior. Converted back to original behavior writes fail silently.

I'm a bit unsure is this the correct way to handle things but I made an assumption that the ExhaustibleBlockDevice is supposed to silently discard writes instead of producing errors.

Summary of changes

Impact of changes

Migration actions required

Documentation

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

@0xc0170
@michalpasztamobica
@SeppoTakalo

---

[ciarmcom]

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

[0xc0170]

CI started meanwhile

[mbed-ci]

Test run: FAILED

Summary: 1 of 3 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_unittests

[0xc0170]

As expected, unittest failed

[michalpasztamobica]

I reproduced those locally and can provide a fix soon.

[michalpasztamobica]

@VeijoPesonen , @0xc0170 I added a commit with the unittests fixes on my fork: https://github.com/michalpasztamobica/mbed-os/commits/fix_blockdevice
With these changes the Unittests are passing (and some comments explain that we now expect erase to to fail silently).
@SeppoTakalo , do you also understand that ExhaustibleBlockDevice should be failing silently once erase cycles are over? A few months ago I modified the code, so that the device returns an error if erase is not possible, but it was just how I personally thought the device should behave. I might have been wrong.

[SeppoTakalo]

I'm just assuming that it was developed to simulate flash behaviour, and in many cases the flash writing might fail, and only way to ensure that is to read back the content. Therefore not returning error, when we don't write, is the closest possible behaviour of that imaginary driver on dying flash.
Some flash drivers might note that flash have died, I'm not sure, but lets assume that they don't. That is the trickiest, so this should help to test those tricky situations.

[VeijoPesonen]

@0xc0170 I cherry-picked @michalpasztamobica's unit tests changes.

[VeijoPesonen]

Need to admit this was a bit hard to figure out what is the right behavior. Maybe if flash would be having ECC enabled we would get proper errors if writes fail. I don't really know.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 6 of 6 test jobs passed
Build number : 2
Build artifacts