fix(server): use a new db worker for hot updates

[afdesk]

Description

the first updating uses a new client instance, but hotUpdate uses the same client instance for all attempts.
we should use a new client for each update, because the client doesn't populate a new artifact.

Related issues

• Close Is it correct that the Trivy Server Mode Vulnerability DB update is normal? #2187
• Close can't update the trivy database in ClientServer mode #2579

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

I think we should add Refresh or something like that in db.Client. It forces to update artifact. We may want to change populateOCIArtifact() to populateOCIArtifact(false bool).

func (c *Client) populateOCIArtifact(force bool) error {
	if c.artifact == nil || force {
		repo := fmt.Sprintf("%s:%d", c.dbRepository, db.SchemaVersion)
		art, err := oci.NewArtifact(repo, dbMediaType, c.quiet, c.insecureSkipTLSVerify)
		if err != nil {
			return xerrors.Errorf("OCI artifact error: %w", err)
		}
		c.artifact = art
	}
	return nil
}

[knqyf263]

I found force is always true... Can we simply populate it anytime by removing the if-statement?

[afdesk]

I found force is always true... Can we simply populate it anytime by removing the if-statement?

yes, I wanted to write the same comment.

[knqyf263]

We should test it carefully, image scanning, client/server mode, Kubernetes scanning, etc. I don't remember, but there was a reason to avoid multiple initializations. It may be no longer necessary after some refactoring though.