lang: add realloc constraint group

[callensm]

Creates a new constraint group to include the usage of realloc = <new_space>, realloc::payer = <account>, and realloc::zero = <bool> constraints.

Handles the transfer of lamports between the reallocated and allocator accounts based on the delta-bytes (additive vs subtractive reallocation).

closes #1917

[callensm]

open discussion on how to handle the data zeroing option in the AccountInfo::realloc function.

currently set to false, but was wondering if that should also be open to a third constraint in the new group.

[armaniferrante]

We should add docs on this here https://github.com/project-serum/anchor/blob/master/lang/derive/accounts/src/lib.rs before merging.

[armaniferrante]

open discussion on how to handle the data zeroing option in the AccountInfo::realloc function.

currently set to false, but was wondering if that should also be open to a third constraint in the new group.

Does zero_init only zeroize the new bytes that are added? Or does it zeroize the entire account?

[callensm]

Does zero_init only zeroize the new bytes that are added? Or does it zeroize the entire account?

Its for zero initializing new memory, however, the docs have this caveat...

Note: Memory used to grow is already zero-initialized upon program entrypoint and re-zeroing it wastes compute units. If within the same call a program reallocs from larger to smaller and back to larger again the new space could contain stale data. Pass true for zero_init in this case, otherwise compute units will be wasted re-zero-initializing.

[armaniferrante]

@callensm based on that comment it sounds like one would almost never need to pass in that parameter. Nevertheless, I'm thinking we should force the developer to be explicit in their intention and pass in this parameter regardless, so that they at least are forced to read the docs and understand what is happening. It's ugly, but a bit safer in the event there's a reason one actually needs to re-zero-initialize (e.g., they call try_accounts manually in the instruction handler).

[callensm]

@armaniferrante sounds good. next commit will contain resolutions for your suggestions above (renaming allocator to realloc::payer and docs) and adding a third realloc::zero constraint to the group for this rare use-case

[cavemanloverboy]

from the solana source code:

    /// Note:  Account data can be increased within a single call by up to
    /// `solana_program::entrypoint::MAX_PERMITTED_DATA_INCREASE` bytes.

perhaps we can give an informative error if delta_space exceeds this? Not sure what that error looks like on the Solana end.