Identity com bugfix/robust fetch nullable

[Henry-E]

#2174

Had to create a new PR because the original came from a company account which couldn't accept changes from maintainers.

[vercel]

Someone is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[stegaBOB]

Are there any cases where this wouldn't work? Could this be improved by checking the owner to check if its owned by the system program?

[Henry-E]

To be honest I'm not even sure what fetchNullable is for. But it seems unlikely that this would just be useful for system program accounts maybe? There could be program owned accounts that just store solana and no data. Though again, I'm not really very familiar with this function.

@rado0x54 might be able to comment on what the use cases are that they've been using it for?

[Henry-E]

Ok, given that the definition of fetchNullable is Returns a deserialized account, returning null if it doesn't exist. it seems reasonable that it would also return null if the account has no data on it? Since the whole point of fetch is to return the deserialized account data. So I think this is probably an ok expansion or "fix" to the behaviour of fetchNullable, since I think right now the function will just outright error if it tries to decode the account's data when it has lamports but no data. So it's actually preventing the function from erroring and making it more robust. Anyone who disagrees is free to voice their opinion and we can look into undoing the change later.