Make attribute writing be dependent on attr_count upon close/sync and not upon open

[amgross]

Current user attributes behavior given upon open to write is bit complicated:
If attribute count is not 0 upon open:
At the first sync (or close) after the open things will be written to the disk (in cost of wear etc.) even if user decided not to write attributes and changed attribute count to 0 (maybe wanted to read attributes upon open and according that decided not to update them?).
at next syncs (or close) will write user attributes will be re-written (and changed if user changed them in the buffer) just if the file changed till then.
If attribute count is 0 upon open:
syncs (or close) user attributes will be re-written (and changed if user changed them in the buffer) just if the file changed till then.

This is complex behave, and in cases for example that user opened file with READ-WRITE and wanted to read attributes it will cause write to flash even if he decided not to change anything.

Solution in this fix
The write of the user attributes will be done if and just if file was opened to write and attribute count is greater than 0 upon the close/sync.

tests that added (and will fail without this PR):

1. if upon open attribute count was 1 and upon sync it was 0 and no change done to the file - there was no write to the file metadata (file position stay same)
2. changing attribute count to 1 before sync cause write of the user attributes to the file, even if the file wasn't change (before the fix it happened just in first sync after opening if the attribute count was bigger than 0 upon opening).
3. if multiple syncs happen when attribute count is bigger than 1, each time attributes will be written. (this is reasonable behavior, but user need to be aware of it if fore some reason it calls lots of syncs without any change and the attribute count is bigger than 0 each sync will cause write to the disk)

[geky-bot]

Tests passed ✓, Code: 17132 B (+0.0%), Stack: 1448 B (+0.0%), Structs: 812 B (+0.0%)

	Code	Stack	Structs		Coverage
Default	17132 B (+0.0%)	1448 B (+0.0%)	812 B (+0.0%)	Lines	2439/2600 lines (-0.0%)
Readonly	6234 B (+0.0%)	448 B (+0.0%)	812 B (+0.0%)	Branches	1292/1628 branches (+0.1%)
Threadsafe	17984 B (+0.0%)	1448 B (+0.0%)	820 B (+0.0%)		Benchmarks
Multiversion	17204 B (+0.0%)	1448 B (+0.0%)	816 B (+0.0%)	Readed	29000746676 B (+0.0%)
Migrate	18796 B (+0.0%)	1752 B (+0.0%)	816 B (+0.0%)	Proged	1482895246 B (+0.0%)
Error-asserts	17956 B (+0.0%)	1440 B (+0.0%)	812 B (+0.0%)	Erased	1568921600 B (+0.0%)

[geky]

Hi @amgross, thanks for creating a PR for this (and for writing tests!)

Sorry about the very late response. littlefs2 is currently under a "feature-freeze" to help focus on completing littlefs3 (#1111, unstable), so I appreciate this PR but unfortunately will not be able to review/merge it anytime soon.

The attr API is also being reworked in littlefs3, with some plans to adopt lfs3_file_setattr/getattr to simplify file-attached attrs (#1076 (comment)). So the attr API may look very different in the future.

I'll try to revisit this when actionable, but in case a forget, feel free to reopen or ping this PR after littlefs3 work lands.