Update error wording to reflect actual cause

[losman0s]

Problem

Error message thrown in case of wrong account ownership is too restrictive, and can mislead the developer.

Any Account<'info, XXX> in an endpoint's derive(Accounts) struct is automatically validated at runtime to be owned by the program (~crate) it was created in (c.f. here for the check, and here to see how the #[account] macro automatically sets an account struct's owner). However, when a client call provides an account owned by an unexpected program, the validation fails (good) with the confusing error message The given account is not owned by the executing program (bad).

This does not reflect that fact that an account can very well be owned by any program other than the one executing.

Summary of Changes

Move to suggested error enum name and error message:

#[msg("The given account is owned by a different program than expected")]
AccountOwnedByWrongProgram,

Fixes #1100

[paul-schaaf]

@losman0s pls sign the commits in this pr and force push

[losman0s]

@losman0s pls sign the commits in this pr and force push

@paul-schaaf Done

[paul-schaaf]

Problem

Error message thrown in case of wrong account ownership is too restrictive, and can mislead the developer.

Example: an Account<'info, MyData> in an endpoint's derive(Accounts) struct is validated to be owned by program Z (#[account( owner = Z::ID )]), but when a client call provides instead an account owned by Y, the validation fails (good) with the confusing error message The given account is not owned by the executing program (bad).

Summary of Changes

Move to suggested error enum name and error message:

#[msg("The given account is owned by a different program than expected")]
AccountOwnedByWrongProgram,

Fixes #1100

this is not correct btw. this error is not thrown when an owner check fails (which would be the ConstraintOwner error)

[paul-schaaf]

#1154 (comment)

because this is wrong, the changelog isnt quite accurate either. this change does not affect the owner validation macro. It's the Account<'a, T> owner validation that fails

[losman0s]

@paul-schaaf Does the updated PR description and changelog fit better now?

[paul-schaaf]

@losman0s yes