Add DatabaseAuthenticationConfig and other changes for improved passwordless db configuration

[chad-cwc]

This PR updates the SDK as needed for the passwordless database UX improvements I added to the back end. In the API changes, the DatabaseAuthenticationConfig fields are all typed as strings and are not individually validated on the back end; however, the entire object is validated as being one supported by the BastionZero service. For convenience in writing client code, the valid values for each field defined in DatabaseAuthenticationConfig are provided as constants in the dbauthconfig package.

Related webshell-backend PR: https://github.com/bastionzero/webshell-backend/pull/1639

[ymarcus93]

This used to be Port and no omitempty. I think we should keep it like that because this field is still required when creating a db target, so no need to make it a pointer

[chad-cwc]

Did you read the comment above the field? Maybe it's not clear, but I made a change in the API to allow it to be null for one specific db type. So, I thought it was appropriate to make this change. We could make it required in this SDK, though, if that makes sense. I'm not sure it does, though.

[ymarcus93]

Oh right. Sorry yeah I missed that. It's unfortunate though in Go that this would still be considered a breaking change cause now the field type has changed to a pointer type. Maybe this is evidence that we should be using pointer types everywhere just in case one day a field does become optional by the remote API. Because otherwise, we'll run into this again and cause it to break for those who expected it not to be a pointer type

[chad-cwc]

OK. Good point. We could change it back for now and change the comment to explain that the port doesn't matter for CCP-hosted databases. Then, add it to a backlog of breaking changes, which I think maybe you mentioned???

Or, of course, go forward with the breaking change.

[ymarcus93]

Honestly, you could still keep it as before (no pointer type) and then in the case of GCP where it isn't required, people just won't set the field and that will end up getting serialized to:

{"remotePort":{}}

but backend should interpret that and set it to 0 the default type of the integer I think?

[ymarcus93]

So some extra bytes are sent but at least it is still backwards compatible. And then in future breaking release (batch other pending breaking changes), we can make the change you did earlier, making it a pointer type.

And then, I think we honestly should have a discussion of just making everything pointer type to prevent this from being a breaking change in the future. I'm starting to realize this is prob why the Go GitHub SDK has everything as pointer types--to prevent a situation like this where remote API makes a field optional at some point in the future.

The only annoying this is it makes using the API a little bit harder to use cause you have to make everything pointers. Luckily, though we do have a helper method to make pointers

bastionzero-sdk-go/bastionzero/bastionzero.go

Lines 301 to 304 in 02301e7

	// PtrTo returns a pointer to the provided input.
	func PtrTo[T any](v T) *T {
	return &v
	}

But it's also cumbersome for users to have to check if pointer is non-nil before reading value. But we can remedy this with getters like we've done before on other pointer fields or autogenerate them like the Github Go SDK

[chad-cwc]

but backend should interpret that and set it to 0 the default type of the integer I think?

Not quite. The value for Port.Value is required by the back end, so it would error out.

I'll add a TODO as we discussed offline and will update the comment to something appropriate.