cargo-php: smoke testing the extension before enabling it in php.ini

[kakserpom]

The state of things:
Currently cargo php install adds a newly built extension unconditionally given that the building process itself hasn't failed.

As a Mac user I sometimes end up having a broken extension file, which causes the PHP interpreter get instantly killed off right after startup. When it happens I have to manually remove extension=... from php.ini, then run cargo php remove --yes and then cargo php install --yes.

Proposal:

1. cargo php install should make sure that the newly built extension can be loaded without errors. It can be done by running php -d 'extension=foo.so' -r '' and asserting that the exit status code is 0.
2. cargo php install should update a symlink instead of overwriting the extension itself https://github.com/davidcole1340/ext-php-rs/blob/master/crates/cli/src/lib.rs#L224-L226
   copy() being a non-atomic op, truncates the destination file and writes it block by block, so there's a chance to load a broken extension file.
   I believe this is also the reason for the random MacOS issues.
3. I think --yes has to go. Let's add cargo php build for building without installing. cargo php install should build and install without prompting a yes. Prompting during cargo php remove doesn't seem logical either.

[Xenira]

1. Like the idea. Probably should also add a flag here, that allows disabling that behaviour.
2. From where to where should we link here? Need to place the extension somewhere. Keeping it in the target folder is not a good option imo. Files in that folder should not be considered permanent. Think this should be an opt-in functionallity.
3. Not sure about that. It is a destructive option and should prompt by default.

[kakserpom]

@Xenira

2. cargo php install should copy a new extension file from target to extension_dir (with a new name) and then change the symlink so it points to the new one and then safely delete the old extension file. It will solve MacOS issue too.
3. How is it destructive? It's easily reversible.

[Xenira]

2. cargo php install should copy a new extension file from target to extension_dir (with a new name) and then change the symlink so it points to the new one and then safely delete the old extension file. It will solve MacOS issue too.

So we have both say a libext..so and a symlink to that folder inside the extension_dir?

3. How is it destructive? It's easily reversible.

and then safely delete the old extension file

Also in 3.

Let's add cargo php build

Thats what cargo build is for.

I would focus on implementing 1) first. That is a hard yes from my side. The other 2 require some more thought.