Place ttrpc files in OUT_DIR

[jprendes]

This PR places the generated ttrpc files in OUT_DIR, and makes the files generation unconditional.
This avoid commiting the generated files to the repo.

[Mossaka]

it probably will make it difficult to discover where the generated files are. Could you please add some guidence on this?

[jprendes]

The actual location of OUT_DIR is an implementation detail of cargo.

Do they need to be discoverable?
The .proto file is discoverable and what we should care about.

As I see it, the generated files are just an artifact.
They are not really intended for human consumption, we don't even lint them.

[jsturtevant]

This is similiar to how rust-extension project does it as well https://github.com/containerd/rust-extensions/blob/2f0ffb98b5dcf5e5473775bcf9e49abf0ccbc9f0/crates/shim-protos/src/shim.rs#L17-L19

[jsturtevant]

LGTM

[Mossaka]

lgtm!

[Mossaka]

It seems like this needs a rebase.

[cpuguy83]

Why would we not commit the files to the repo?

[jprendes]

Why would we not commit the files to the repo?

It's generally good practice not including generated files.

They are a distraction and can be confusing.
It adds noise to the makefile, which is currently in charge of generating these files before building.
It adds a seemingly useless (for downstream consumers) feature to the crate.
Also contributors might think it's ok to modify them manually, just for their changes to be lost the next time they are generated.
Their content is an implementation detail of ttrpc-rust, not particularly human friendly code.
Also, if we move to shims v3, are we going to have the ttrcp-rust generated files for ttrcp and the tonic generated files for the grpc implementation?

There's also no benefit to having them in the repo.
Build time impact is negligible (they are generated only once, cargo keeps track of this).
It does need protoc installed, but we already need it for rust-extensions.

[Mossaka]

LGTM!

[cpuguy83]

This is fine I guess.
I expect it to break code lookups since those types are no longer there, but I guess the files are being generated when it compiles them for code analysis.

[jprendes]

Lookup works fine with rust-analyzer on vscode.
As @jsturtevant mentioned, it's the same approach as in containerd/rust-extensions