general_block_device test: support non-uniform erase sizes

[LDong-Arm]

Summary of changes

Fixes: #12575

Several test cases in the general_block_device test assume one erase/sector size exists across the whole flash, which is not always true. BlockDevice::get_erase_size() (no parameter) returns 0 to indicate the lack of a common erase size:

mbed-os/storage/blockdevice/COMPONENT_QSPIF/source/QSPIFBlockDevice.cpp

Lines 493 to 497 in 54f0f56

	bd_size_t QSPIFBlockDevice::get_erase_size() const
	{
	// return minimal erase size supported by all regions (0 if none exists)
	return _sfdp_info.smptbl.regions_min_common_erase_size;
	}

But this doesn't mean the test can't work in such scenarios - in fact it has nearly all the bits and pieces to support non-uniform erase sizes. We just need to refrain from using the vague get_erase_size() but use get_erase_size(addr) instead:

• test_program_read_small_data_sizes uses one sector only, so we simply get the size of that particular sector.
• For read/write buffers allocated in preparation for basic_erase_program_read_test(), we only need to make sure it's large enough for the largest sector. Then basic_erase_program_read_test() can already handle variable sector sizes and only use part of our buffer as needed.

Additionally, this PR improves the heap allocation error message for targets with very large sectors (e.g. 256KB) but small RAMs.
Potential improvement for this(?): In my opinion allocating read/write buffers equal to sector size is way too much and doesn't always work as said. Read and write operations are much more fine-grained (one byte to < 1KB), so in principle we can use smaller buffers and break down operations with a loop...

Impact of changes

It should fix flashes that don't have a common erase size across regions, such as CYW9P62S1_43012EVB_01 in #12575 - to be tested.

Migration actions required

None.

Documentation

None.

---

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

@miteshdedhia7, @ARMmbed/mbed-os-storage, @ARMmbed/mbed-os-core

---

[ciarmcom]

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

[evedon]

Code change looks good.

It would be useful if @miteshdedhia7 can confirm that this fixes #12575

[mbed-ci]

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-ARM	✔️
jenkins-ci/mbed-os-ci_build-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️