[FL-3884] Proper integer parsing

[portasynthinca3]

What's new

• Adds the following string to integer conversion API functions that verify input validity including overflow checks (header lib/toolbox/strint.h):

  StrintParseError strint_to_uint64(const char* str, char** end, uint64_t* out, uint8_t base);
  StrintParseError strint_to_int64(const char* str, char** end, int64_t* out, uint8_t base);
  StrintParseError strint_to_uint32(const char* str, char** end, uint32_t* out, uint8_t base);
  StrintParseError strint_to_int32(const char* str, char** end, int32_t* out, uint8_t base);
  StrintParseError strint_to_uint16(const char* str, char** end, uint16_t* out, uint8_t base);
  StrintParseError strint_to_int16(const char* str, char** end, int16_t* out, uint8_t base);

• Adds unit tests for these new functions
• Changes existing code to use these new functions instead of sscanf and strtol and friends wherever warranted and possible

Verification

Run unit tests

Remarks

• "strint" is not a typo, it's short for "string & integer"
• not really sure if the API version in api_symbols.csv is correct

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[github-actions]

PVS-Studio report for commit 2a4d8401:

• Report

[hedger]

Please sync all targets' API versions.
./fbt TARGET_HW=18

[github-actions]

Compiled f7 firmware for commit df6d9ad3:

• 📦 Update package
• 📥 DFU file
• ☁️ Web/App updater
• 📊 Size report

[portasynthinca3]

Not sure how to fix the PVS-Studio diagnostic. I see two possible causes:

• PVS-Studio thinks that strint_to_int32 might access the provided out outside the first element. This just does not happen.
• PVS-Studio thinks that int and int32_t have different sizes. This is not the case with our platform.

[portasynthinca3]

Thank you, I'll address these comments.

[CookiePLMonster]

Thank you, I'll address these comments.

Looks nice now! Do you think it also makes sense to replace all uses of atoi?

[portasynthinca3]

Looks nice now! Do you think it also makes sense to replace all uses of atoi?

Yep, I think so too. I'll do that tomorrow.

[CookiePLMonster]

One more nitpicky, but (technically) code-size-reducing comment.

[CookiePLMonster]

@skotopes Does it make sense to strip away atoi, strtol and friends from the firmware/API now that this is available?

[skotopes]

@CookiePLMonster yes, but we are not going to do it because external libraries/code may depend on it.

[CookiePLMonster]

Yeah that makes sense, if third parties use it you'll not save any flash space anyway, so might as well keep exposing it...