Add support for GPG Keys API

[sebasslash]

Adds support for the GPG Keys API

This PR also modifies the client to support the registry base path: /api/registry. To keep the client's internal interface consistent I've added an extra check in newRequest() that will parse the path variable; if a request is made to the Private Registry API the url must explicitly contain the base path so that the client can set the appropriate registry base path. As far as the TFC/E API is concerned, the GPG Key endpoints are the only ones that use the registry's default path.

To run individual tests:

go test -run TestGPGKeyCreate -v ./... -tags=integration
go test -run TestGPGKeyRead -v ./... -tags=integration
go test -run TestGPGKeyUpdate -v ./... -tags=integration
go test -run TestGPGKeyDelete -v ./... -tags=integration

[annawinkler]

When we talked about these URLs last week, did we say that we would create a new request type for the private registry API endpoint? 🤔 I didn't take notes so I'm not remembering unfortunately.

[sebasslash]

Yep! but these improvements will be made after the fact since they are only internal changes.

[annawinkler]

Thanks for adding support for this API! I've left a few comments and questions. ✨

[annawinkler]

💯 Nice!

[annawinkler]

What do you think about adding a test if the key doesn't exist or is invalid?

[sebasslash]

This will return a 404, however we don't need to add a test for this. The reason being is the client in client.do() decodes the headers and returns the appropriate generic error. In this case that would be ErrResourceNotFound.

[annawinkler]

When I was reading the docs, I noticed this line: Only the namespace attribute can be updated, and namespace has to match an organization the user has permission to access. I'm curious if the API returns an error if a namespace doesn't match an org the user has permission to access? Would this be something we would want to add a test for? The reason I suggest adding a test is because this detail could be overlooked by someone using this API, and they might see a test. I also admit that we don't want to cross a boundary if it doesn't make sense. What do you think? 🤔

[sebasslash]

Good catch and this makes way more sense here as we want to test for an error that's specific to this resource! I've added a check in the error handler for client.do() inside GPGKeys.Update() where if the body's message contains namespace is not authorized it will return ErrNamespaceNotAuthorized. I've also added the corresponding test.

[annawinkler]

I have mixed thoughts on not taking a parameter for the registry-name (which must be private). The API docs specify this as a parameter, and this is a parameter for the private registry provider APIs. What are your thoughts about this @sebasslash ?

[sebasslash]

Hmm, well since it's always going to be private, I'd rather not expose it as part of the interface.

[annawinkler]

🏅 This is looking really good! I have one more question that relates to the private registry provider APIs and how we want to deal with a parameter (in this case registry-name) that can only have one value.

[annawinkler]

🥇 Looks great!

[github-actions]

Reminder to the contributor that merged this PR: if your changes have added important functionality or fixed a relevant bug, open a follow-up PR to update CHANGELOG.md with a note on your changes.