feat(http)!: automatically encrypt cookies

[innocenzi]

This PR builds on #1346 to automatically encrypt cookies. This PR does not include an option to have plain-text cookies.

What required the most attention with this PR was the internal tests—we now really need to have a SIGNING_KEY. For this reason, the tests' bootstrap calls key:generate under the hood.

An alternative could have been to add hardcoded configs (like tests/Integration/encryption.config.testing.php and tests/Integration/signing.config.testing.php), but the HTTP client tests start an actual server outside of the testing environment, to which I couldn't pass through the SIGNING_KEY environment variable.

[brendt]

Shouldn't we just force the SIGNING_KEY to be present at all times by checking it in the kernel and throwing an exception if it's not present.

Maybe even better, why not generate it automatically (as in: write it once to .env) if it's not set? Is that too much magic?

[innocenzi]

Shouldn't we just force the SIGNING_KEY to be present at all times by checking it in the kernel and throwing an exception if it's not present.

Yeah, probably! I'll explore this.

Maybe even better, why not generate it automatically (as in: write it once to .env) if it's not set? Is that too much magic?

I kinda like this. The main issue I can see happening is that if we generate a signing key because it's missing in .env, things can get corrupted really quick if the missing key in .env was a mistake and there was already existing encrypted data

[innocenzi]

Yeah, probably! I'll explore this.

Went to implement this and realized it doesn't make too much sense. Only tempest/http requires it right now for the cookies, so even though technically SIGNING_KEY would be always needed, I prefer having the logic of throwing at initialization time in the encrypter component

[brendt]

Ok, I'm good to merge if you are happy with it

[innocenzi]

Nice!