Increase size limit for payload formatter scripts

[neoaggelos]

Summary

References #4053
Closes #4278

Testing

...

Regressions

...

Notes for Reviewers

I think I saw somewhere a standard limit of 64KB being mentioned, but went with the 40KB limit proposed in the issue.

Let's choose a value and avoid more PRs like this in the future.

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[htdvisser]

As @johanstokking wrote in #4278 (comment):

Currently, there's a LoRa Alliance task force under TC about Codec API where a limit is being defined. I think we'll end up somewhere in the range of 32 to 40 KB.

So I think that for now we should go for 32kB, and depending on the outcome of LoRa Alliance discussion increase it to 40kB.

[johanstokking]

I also said #4278 (comment), echoing @adriansmares's proposal. That's implemented here.

The LoRa Alliance decision is going to take a while because we also want to settle on a library that gets pre-loaded, i.e. Node's Buffer polyfill, maybe some crypto functions and maybe some CRC functions. Once that is defined, we have a better idea of what is sensible for the device maker to implement themselves, and come up with a sane limit.

Now, until we have that, I would in fact relax this for now, because this is really limiting at the moment. So let's settle on 40 KB in API and 40 KB in AS allowed maximum. Whenever we have Buffer, crypto and CRC32, we will once again reduce the AS allowed maximum, aligning with the LoRa Alliance technical recommendation. So this is good to go as-is.