https://github.com/anchore/grype/issues/467 was migrated from syft to grype and should have been in the release notes for grype v0.24.0, but it was missing and had to be manually added.

Today, running chronicle without a chronicle config you see:

failed to load application config: 
        invalid application config: bad log level configured (""): not a valid logrus Level: ""

This PR fixes this while also switching over to the anchore logger interface.

There is a lot of non-github specific changelog generation logic that resides in the github changelog worker; this PR abstracts that logic to a more central spot, the release package.

Specific changes:

• Add release.ChangelogInfo() to get the last release and a description that will make up the current changelog
• Abstract the git helper methods to an interface for easy mocking in testing
• Abstract version speculation behind a new release.VersionSpeculator interface and split the current logic between the release and github package
• Add the gosimports linter
• Upgrade golangci-lint to v1.45.0
• Disable CI response to git push events

In cases where there is already a release for a speculative release version, now that version will be skipped and the next best patch version will be used.

If you have a config where log.level is set and you provide -vv chronicle would error out. The correct behavior is to honor the cli option (which should override env vars and config files)

A new CHRONICLE_GITHUB_ISSUES_REQUIRE_PRS boolean configurable to optionally only consider issues that have linked PRs that are merged as changelog entry candidates. Additionally adds configuration documentation

Follow up from https://github.com/anchore/chronicle/pull/27 ; we shouldn't consider PRs from the last release when making the changelog for this release.

Adds the ability to speculate what the next release version might be from the set of changes discovered. This is expressed as two new features:

1. Adding a next-version command

# last github release: v0.1.0 
# state: one bug and one feature added since v0.1.0

$ chronicle next-version .
v0.2.0

2. Allow the create command to speculate the next version instead of report "unreleased"

# same release / repo state from (1)

$ chronicle > /tmp/changelog-1.txt
$ chronicle -n > /tmp/changelog-2.txt

# diff /tmp/changelog-1.txt /tmp/changelog-2.txt
3c3
< ## [(Unreleased)](https://github.com/wagoodman/chronicle-test/tree/4e685278ed9a268806c4d7fe534d2d58d6ca0d70) (2022-03-24)
---
> ## [v0.2.0](https://github.com/wagoodman/chronicle-test/tree/v0.2.0) (2022-03-24)
5c5
< [Full Changelog](https://github.com/wagoodman/chronicle-test/compare/v0.1.0...4e685278ed9a268806c4d7fe534d2d58d6ca0d70)
---
> [Full Changelog](https://github.com/wagoodman/chronicle-test/compare/v0.1.0...v0.2.0)

There is an edge case where if an issue or PR close timestamp matches the same timestamp as the release the changelog is being generated for, then the PR/issue in question is filtered out:

[0000] DEBUG github owner="wagoodman" repo="chronicle-test" path="../chronicle-test"
[0000]  INFO since tag="v0.0.0" date="2022-03-23 20:24 UTC"
[0000]  INFO until tag="v0.1.0" commit="5d95ff3aba8b6619b59f85f24332bc3ab5b0ae11"
[0000] DEBUG total merged PRs discovered: 2
[0000] TRACE PR #2 filtered out: merged after 2022-03-23 20:19 UTC (merged 2022-03-23 20:19 UTC)
[0000] DEBUG PRs contributing to changelog: 1
[0000] DEBUG total closed issues discovered: 0
[0000] DEBUG issues contributing to changelog: 0
[0000]  INFO discovered changes: 1
[0000] DEBUG   └── added-feature: 1

The correct behavior (which this PR fixes) is to keep the edge PR/issue included in the list of changes:

[0000] DEBUG github owner="wagoodman" repo="chronicle-test" path="../chronicle-test"
[0000]  INFO since tag="v0.0.0" date="2022-03-23 20:24 UTC"
[0000]  INFO until tag="v0.1.0" commit="5d95ff3aba8b6619b59f85f24332bc3ab5b0ae11"
[0000] DEBUG total merged PRs discovered: 2
[0000] DEBUG PRs contributing to changelog: 2
[0000] DEBUG total closed issues discovered: 0
[0000] DEBUG issues contributing to changelog: 0
[0000]  INFO discovered changes: 2
[0000] DEBUG   └── added-feature: 2

For example:

## [v0.27.0](https://github.com/anchore/syft/tree/v0.27.0) (2021-10-21 15:23:34.232633 -0400 EDT m=+2.137022651)

Should be:

## [v0.27.0](https://github.com/anchore/syft/tree/v0.27.0) (2021-10-21)

For example:

# Changelog

## [v0.27.0](https://github.com/anchore/syft/tree/v0.26.0) (2021-10-21)

Should be

# Changelog

## [v0.27.0](https://github.com/anchore/syft/tree/v0.27.0) (2021-10-21)

When an annotated tag is present Chronicle errors out with following:

unable to summarize changes: object not found

While doing some debugging it appeared that chronicle has a hash for the annotated tag that does not actually match the hash of the commit it is referencing which seemed to be the cause of the failure to find object

It is common to have an issue represent the total work to be done and split up that work across multiple PRs. In this case there would be a merged PR with an issue that is still open. When we detect this case, what should we do? Report out the partial feature based on the PR information? Hold back from reporting the entry in the changelog since the issue isn't closed? Or something else.

(My preference is to hold of from including it in the changelog until the linked issue is closed, but was curious for other thoughts here)

We use the v4 github API to limit the amount of information returned and the number of queries that need to be made. However, it is still possible with large repos to hit rate limits. It would be ideal to track this information with each query and be smart about retries with the information gleaned from the rate limit section of the responses.

There could be cases when you want to take the set of partial changelogs and generate a full changelog from all previous releases. A command that is capable of doing this without having to recreate the changelog from the set of PRs and issues would be ideal --especially if there were manual changes made to the changelog (which is common).

In cases where you generate a changelog but there are issues that were closed by have no labels. This would give you the option to have a section for the "remaining" issues that were closed in the release that fall into this category. From there someone could manually fit these issues into the right changelog sections (e.g. bug fix, enhancement, etc).