Crop avatars with Imgproxy

[Soxasora]

Description

Fixes #1778
Client-side cropping wasn't giving the best of results, this PR introduces cropping via Imgproxy's Crop feature giving better cropping results.

Screenshots

This keyboard pic zoomed at 250% from 200x200 makes a huge case for server-side processing

left: Imgproxy - right: React Avatar Editor

Additional Context

It required minimal changes, now React Avatar Editor is only used to get cropping values. With them we can now upload the untouched image to S3 safely and create an Imgproxy path to crop it.
We then upload the cropped image back to S3. This is a standard approach that imo could be better than serving imgproxy urls on avatars since if imgproxy goes down, every avatar would go down. It also fits nicely with already existing avatars and db schema.

Checklist

Are your changes backwards compatible? Please answer below:
Yes, it uploads the Imgproxy cropped photo back to S3 to also retain the existing setPhoto

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
7, consistent good results

For frontend changes: Tested on mobile, light and dark mode? Please answer below:
n/a

Did you introduce any new environment variables? If so, call them out explicitly here:
n/a

[huumn]

I'd guess this works fine but I'm having trouble QAing in the normal dev setup. It returns a url with imgproxy as the hostname.

Do I need to modify my env or something?

[Soxasora]

const IMGPROXY_URL = process.env.IMGPROXY_URL_DOCKER || process.env.NEXT_PUBLIC_IMGPROXY_URL

IMGPROXY_URL is based on IMGPROXY_URL_DOCKER in dev, in prod is instead based on NEXT_PUBLIC_IMGPROXY_URL

Since I tested it with HTTPS I just blanked the docker env var and used the public Imgproxy url. Basically docker containers can't use localhost with each other, they have to use hostnames instead.

But this is actually a thinking error because the upload happens client-side so it might be appropriate to return a NEXT_PUBLIC_IMGPROXY_URL based URL. Pushing it now, sorry and thanks!

[huumn]

I get a CORs issue now with the default sndev setup.

Access to fetch at 'http://localhost:3001/S_ASkXittsLJXhFYXpH__fGComLBm43_JOp2mHGVNyg/crop:512:512/gravity:fp:1:0.8333333333333333/rs:fill:200:200/aHR0cDovL3MzOjQ1NjYvdXBsb2Fkcy8xOTk1NA' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

[huumn]

Looks like we need to set IMGPROXY_ALLOW_ORIGIN. It'll also need to be set in prod. I'm making these changes now.

[huumn]

Looks like we've had a bug with avatars in sndev for awhile - avatars were using MEDIA_URL from lib/constants which defaulted to the docker hostname. That's not your fault.

For future stuff, it's important our changes work in our common development environment.

[Soxasora]

I honestly disregarded any CORS issue in dev because by running it on HTTPS I kinda expected to receive all kinds of errors. My bad for not looking into it.

For future stuff, it's important our changes work in our common development environment.

Agree! Will be more careful towards dev env experience

[huumn]

No worries! It's hard to appreciate these things - and just easy for me to which is I mentioned it.