Added _t to a couple of the NVS typedefs (IDFGH-891)

[badcf00d]

Just went through and added _t to some typedefs in nvs.h to match the convention. This mainly helps with syntax highlighting, vscode recognises _t as a typedef and highlights it

[CLAassistant]

All committers have signed the CLA.

[projectgus]

Thanks for thinking of us and sending this PR.

I'm going to ask @igrr to weigh in here, because I think he originally chose this name.

There are some complicating factors here:

• Technically, typename_t is reserved by POSIX for use by POSIX types only. Clearly, a large percentage of the world's C code violates this rule and we've violated this rule in many other parts of ESP-IDF.
• Given that we've violated the rule elsewhere, it may be better that we're consistent and violate it here as well. Although I'm not sure about this, especially if we wanted to "do the right thing" in the future.

[projectgus]

We probably don't want to break all existing projects' code which uses nvs_handle, so at minimum we would want another typedef here to maintain compatibility.

[badcf00d]

Yep that's a good point, added back the original typedefs I replaced

[igrr]

There seems to be more code in IDF which uses _t suffix in typedefs than the code which doesn't, so we can probably stick to the "wrong" option. As long as the types are namespaced with an appropriate prefix, the risk of conflicting with a POSIX type should be low.

Agree that a typedef for compatibility with the existing code is needed.

[badcf00d]

Ah ok I didn't realise the _t was originally a POSIX thing, I had just seen it used as the convention when declaring typedefs, but as @igrr says there seems to be more code in the IDF that uses _t than doesn't.

[projectgus]

Thanks for making those changes, @Frosticles . I've cherry-picked this into our internal review & merge queue, with one small additional small change (added a backwards-compatible nvs_openmode to go with nvs_openmode_t).

This PR will be updated when it's merged.