Fix: Do not redact password for conn pool connection uri while connecting to DB

[priyanshi-yb]

Describe the changes in this pull request

Fixing the bug where import data always fails to connect to DB via the connection pool with a password authentication as the connection URLs are getting redacted while passing to the connection pool.
#2204
redaction still happens-

2025-01-18 12:46:14.483348 INFO yugabytedb.go:252 Initialized connection pool with settings: (tgtdb.ConnectionParams) {
 NumConnections: (int) 2,
 NumMaxConnections: (int) 4,
 ConnUriList: ([]string) (len=1 cap=1) {
  (string) (len=81) "postgresql://ybvoyager:[email protected]:5433/pg_datatypes_offline?sslmode=prefer"
 },
 SessionInitScript: ([]string) (len=3 cap=4) {
  (string) (len=29) "SET client_encoding TO 'UTF8'",
  (string) (len=39) "SET session_replication_role TO replica",
  (string) (len=53) "SET default_transaction_isolation = 'repeatable read'"
 }
}

Describe if there are any user-facing changes

Its a fix, no user-facing changes

How was this pull request tested?

automation tests are enough

Does your PR have changes that can cause upgrade issues?

Component	Breaking changes?
MetaDB	No
Name registry json	No
Data File Descriptor Json	No
Export Snapshot Status Json	No
Import Data State	No
Export Status Json	No
Data .sql files of tables	No
Export and import data queue	No
Schema Dump	No
AssessmentDB	No
Sizing DB	No
Migration Assessment Report Json	No
Callhome Json	No
YugabyteD Tables	No
TargetDB Metadata Tables	No

[makalaaneesh]

We're logging the full struct below, so this will mean we'll have to come back to keep updating this copy here whenever we add a new field.

Let's go with redactedParams := *params ?

[makalaaneesh]

Shall we just have host all all all md5 ? Just want to avoid "trust" altogether 😅

[priyanshi-yb]

yeah I started with that only, but somehow yugabyted wasn't coming up with that conf as yugabyte is a default user maybe trust is required for that, I can take that up later after figuring out how to do that

[sanyamsinghal]

We should not do this.
https://go.dev/play/p/NjUBR-pdyd7
This is typical example of shallow copy vs deep copy and can potentially lead to a bug in future again.

I think as a standard practice also, we should always do Deep copy unless there is a usecase for shallow or significant perf implications of deepcopy.

1. Either copy each field separately.
2. Make use of standard deepcopy libraries available (to address @makalaaneesh's concern)
   https://github.com/mohae/deepcopy
   https://github.com/barkimedes/go-deepcopy (this seems to be better maintained)

[makalaaneesh]

Ah, good point!
+1 to use deep copy by default. (unless there are pointers like mutexes/connections/etc. but then again if the struct has such fields, we wouldn't necessarily want to deep copy)

[priyanshi-yb]

Yeah, missed it thanks for bringing it up @sanyamsinghal .
I made this change but missed one more thing to do redaction of urls back for logging.
I am thinking to not blindly deep copy that to just for logging or for the case where we can also add new fields which don't need to be copied, we can add any new field to logged params as well if required.
I can create the params with redaction for all current fields and log, basically revert the last commit
Sounds good?

[sanyamsinghal]

Yeah you can copy each field manually also, just the overhead of maintaining the codepath for logging. But since the code is at one place so it will be fine.

btw do you see any issue with simply creating a deep copy and printing it? I believe this is a one time thing only? (i assume these deepcopy libraries will take care of nested pointer fields)

[priyanshi-yb]

The issue with directly copying the params is that there will still be an overhead of redacting the URLs in ConnectionParams for logging, and this will still be present for any new fields we will add in the future to check if they need redaction.

redactedParams := &ConnectionParams{}
deepcopy.Copy(redactedParams, params)
redactedParams.ConnUriList = utils.GetRedactedURLs(redactedParams.ConnUriList)

So, I think it is better to have the overhead of adding the new field to the logged parameters if required, as it is a sensitive part where we have connection info with passwords.