impl get_target_default_instance for BlockDevice

[paperchalice]

Summary of changes

Call get_target_default_instance in BlockDevice::get_default_instanceso that the behavior matches the document description.
Provide static member function get_target_default_instance for DataFlashBlockDevice FlashIAPBlockDevice QSPIFBlockDevice SDBlockDevice SPIFBlockDevice .

Impact of changes

Migration actions required

Documentation

An application can override target settings by implementing
XXXXBlockDevice::get_target_default_instance() - the default definition is weak.

The implementation in FlashIAPBlockDevice can be improved... When C++20 enabled,
the code can be:

static auto [bottom_address, total_size] = []() -> std::tuple<uint32_t, size_t>
{
    // get flash info
    return {addres, size};
}();
static FlashIAPBlockDevice default_bd(bottom_address, total_size);

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] 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)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[ciarmcom]

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

[0xc0170]

Thank you for the contribution !

Please fix astyle failures. As this is functionality addition, can you improve the commit messages - adding details about what is being added and why.

Do we still need system storage, can these be implemented in each block device and there will always be just one implementation? Same as its done now in the systemstorage using ifdef ?

Pull request has been modified.

[0xc0170]

The event failures are related. Please review travis-ci/events

[0xc0170]

@ARMmbed/mbed-os-storage would you be able to help reviewing?

[VeijoPesonen]

@0xc0170 Excluding the compilation and astyle issues - which CI revealed - changes look good to me. @bulislaw Would it be time to update the @ARMmbed/mbed-os-storage maintainers list?

[VeijoPesonen]

Let's see does this go in before the PR #13244.

[kjbracey]

This does not match the pattern of NetworkInterface or console overrides, and the naming is in direct contradiction.

I am aware the the block device imitation of those has always been wonky, but this still keeps it wonky.

get_target_xxx should be for the TARGET to override, hence the name, The APPLICATION override point is get_xxx.

If you're documenting this as an application override point, drop the "target_".

Really you should have both. That avoids a link failure when trying to build an application that wants to override on a target that wants to override.

I guess this sort of has both - it has an application override point for BlockDevice (but no target, except choosing COMPONENT_X?), and a target override point for each type of device (but not application).