Fix download mode leak for latest and list handlers

[ngshiheng]

What is the problem I am trying to address?

Despite being set to restrict download via the download mode file, the /list and /latest handlers are still returning data to the user.

This presents a serious security issue, as sensitive module information could potentially be exposed to unauthorized parties.

How is the fix applied?

Check if DownloadMode is set to "none" for a specific module. If so, we just return errors.KindNotFound.

How is this tested?

• Use a custom download.example.hcl file containing:

download "secret/module/repo/*" {
    mode = "none"
}

• Before this PR: curl https://proxy.example.com/secret/module/repo/@latest will return data
• After this PR: curl https://proxy.example.com/bad/module/repo/@latest will return not found error (404)

The same behavior applies to /list endpoint.

What GitHub issue(s) does this PR fix or close?

Fixes #1774

[marwan-at-work]

The download mode is strictly for what to do "when a module is not found", which is only for .zip/.info/.mod endpoint, not for /list and latest. For those, you can check the network mode configuration.

Maybe the docs were not clear enough?

[ngshiheng]

Ah, I kinda understand where you're coming from. Though, the docs did mention blocking certain modules as a use case.

Just to explain it from the perspective of our organization, this is one of the primary use cases of Athens - to act as a vendor to supply a set of internal modules to our downstream:

downloadURL = "https://proxy.golang.org"

mode = "sync"

download "company.gitlab.com/repo/a" {
    mode = "sync"
}

download "company.gitlab.com/repo/b" {
    mode = "sync"
}

download "company.gitlab.com/*" {
    mode = "none"
}

In this case, our users should only have access to repo/a and repo/b and nothing more from company.gitlab.com. However, the current behavior of Athens /list and /latest endpoints allows them to query for information that they shouldn't have access to, e.g. company.gitlab.com/repo/c/@latest.