Changelog automation as part of release automation

[carsonip]

Over the years we have invested in release automation, e.g. new minor / patch version github workflows, but changelog has been manual.

Currently it takes time for the release manager, who may not have the context of every PR involved, on each patch release to scan through the commits from the previous tag, and manually identify whether it has user facing impact, and if so, how to describe it in the changelog. See an example of a patch release changelog PR: #14377 . There's also a challenge that a lot of apm-server changes are actually from imported libraries e.g. apm-data, go-docappender, etc, i.e. actual code change sits in libraries, and the change in apm-server is merely a dep bump.

In an ideal world, we would like changelog automation like ES and EA, where changelog files are placed in a folder, then they are gathered on release to automatically generate a complete release notes for a version. This will save context switching time, and reduce errors e.g. missing a line from changelog.

cc @endorama