mbed-coap changelog.md update

[ristohuhtala]

Summary of changes

Update mbed-coap CHANGELOG.md with v5.1.3 information.

Impact of changes

Migration actions required

Documentation

---

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

[x] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

@teetak01 @yogpan01

---

[ristohuhtala]

Changes listed on CHANGELOG.md are in following PRs:
#12147
#12146

[ciarmcom]

@ristohuhtala, thank you for your changes.
@yogpan01 @teetak01 @ARMmbed/mbed-os-maintainers please review.

[0xc0170]

We usually get an update with fixes, was there a reason for splitting into 3? It's easier to review, just as it is split, might not be easier to follow in the log (this is an update from an upstream repository).

[kjbracey]

We usually get an update with fixes, was there a reason for splitting into 3? It's easier to review, just as it is split, might not be easier to follow in the log (this is an update from an upstream repository).

Anna asked for it to be split - I would have gone with the single upstream update myself.

Original was #12124

[adbridge]

We usually get an update with fixes, was there a reason for splitting into 3? It's easier to review, just as it is split, might not be easier to follow in the log (this is an update from an upstream repository).

Anna asked for it to be split - I would have gone with the single upstream update myself.

Original was #12124

My bad. I think I didn't pay close enough attention to the fact this was an actual coap lib update! Although all the changes were in one commit hence my request to split it. Perhaps for these in the future, one PR but with individual commits for each unique change would have been better! This is an area where our documentation is a little vague and something perhaps we should look at in the new year.

[adbridge]

@yogpan01 @teetak01 do either of you also wish to review ?

[yogpan01]

@ristohuhtala I think you misunderstood about PR split. You need to keep the bug fixes into own PRs but then those have to be accompanied with their own CHANGELOG update. It doesn't make any sense to create a PR with just CHANGELOG when the actual fixes are in some other PRs.
I suggest to include the CHANGELOG in #12146 and #12147

[ristohuhtala]

@ristohuhtala I think you misunderstood about PR split. You need to keep the bug fixes into own PRs but then those have to be accompanied with their own CHANGELOG update. It doesn't make any sense to create a PR with just CHANGELOG when the actual fixes are in some other PRs.
I suggest to include the CHANGELOG in #12146 and #12147

I could add change logs to those two PR. This were misunderstanding for me.

[ristohuhtala]

Commit change log file changes to those two PRs.