fix(provider-maxcompute): fixed and refactored maxcompute and oss client caching flow

[ayushi0014]

No description provided.

[rahmatrhd]

do we need to do the same changes in alicloud_ram provider?

[rahmatrhd]

Suggested change

	const assumeRoleDurationHours int64 = 1
	var assumeRoleDefaultDuration = time.Hour

can we directly set the value into duration here?

[ayushi0014]

sure

[rahmatrhd]

let's make it internal

Suggested change

	type AliAuthAccount struct {
	type aliAuthAccount struct {

[rahmatrhd]

can we check if token TTL is also present in from the assume role response, and use it for expiry instead of using default duration

[ayushi0014]

TTL is not present in the assume role response😕

[rahmatrhd]

let's change this to pkg/aliauth/aliauth.go

[rahmatrhd]

i think let's rename ramRoleFromAppeal to overrideRamRole for easier understanding 😀

[rahmatrhd]

let's do the mutex lock & unlock above and below this line only

Suggested change

	delete(p.odpsClients, cachedClientKey)
	p.mu.Lock()
	delete(p.odpsClients, cachedClientKey)
	p.mu.Unlock()

[ayushi0014]

I think we should take the mutex lock at the time we're retreiving the value from map and release it once the delete operation is done. WDYT?

[rahmatrhd]

reading the value doesn't need to lock the mutex but updating/deleting does

[ayushi0014]

I was considering a race condition where a value could be deleted from the map while another instance is reading it. To prevent multiple deletions, I used the lock. But since deleting the same key multiple times doesn’t cause issues in this case, it's not strictly necessary. we should ideally use a read lock (RLock) while reading to avoid potential race conditions. we can defer using it for now

[ayushi0014]

I'll change the implementation to as you suggested