[#5991] feat(gcs): unify the GCS server acount path configuration for fileset and GCSCredentialProvider

[FANNG1]

What changes were proposed in this pull request?

fileset use gcs-service-account-file while gcsTokenCredentialProvider use gcs-credential-file-path, we'd better unify the name, seems gcs-service-account-file is better

Why are the changes needed?

Fix: #5991

Does this PR introduce any user-facing change?

yes

How was this patch tested?

existing tests

[tengqm]

Can you help explain why this change is necessary?

[FANNG1]

Adding an GRAVITINO prefix declares this is a configuration for Gravitino , not for Iceberg, spark, or others, and keep consistent with other properties defined in S3Properties OSSProperties, etc

[tengqm]

@FANNG1 Yes. That was also my first perception of this naming style after having seen it prevail in many packages. But I'm still confused by such public static final strings.
You know, we are writing these code in Java, which is notorious/famous by its class hierarchies. In other words, we are not supposed to write two Foo classes in the same package. Each Foo has its own namespace. A Foo can be a Gravitino Foo and it can be a Iceberg Foo. We differentiate these two Foo classes by using their fully-qualified names. We are not supposed to add another level of complexity to the class hierarchy.

For most of the cases, a org.gravitino.Foo.CONFIG_FILE can be easily differentiated from a org.iceberg.Foo.CONFIG_FILE. Prepending GRAVATINO_ or ICEBERG_ to those variable/constant names is making them longer for no good. If these code is written in Go, for example, I'd strongly advise the other way around. A prefix can help us quickly locate the file where it is defined. Without a prefix, I have to grep the whole directory because GoLang compiler treats the whole directory as a single compilation unit. A variable can be defined in any source code. That design sucks.

I have seen simply too many cases where our contributors are repeating (copy-pasting) this pattern, and that is the reason I'm putting this forward for the team to reconsider, if appropriate.