Do not require file URL / ingest file contents for fees calculation

[nonprofittechy]

Working in LITeFile, I noticed that the fees calculation requires the public URL for the file you are submitting, and that the proxy server actually downloads that file. Makes local deving harder, but also I'm wondering if this is really needed. I'm trying to figure out why fee calculation needs to see the actual document. Seems like it would slow down fee calculation as well.

It would be nice to allow the submission to be in POST data instead of a public URL that the remote server GETs. I can see some tradeoffs there--the GET method allows for larger files, but it's also likely to be less secure, and is harder to confirm/experiment with a local workflow or maybe in automated tests as well.

[nonprofittechy]

FWIW doing a workaround for now - added a static test file to LITeFile that we'll share instead.

[BryceStevenWilley]

Reducing the amount of info required for a fees calculation is a duplicate of #403 (we're in agreement there, but it's just hard to know what exactly Tyler requires for a fees check; it's way more than you'd expect), but switching from URLs for file storage is a new thing, so rescoping this issue to just that.

You landed on the same approach I had for testing, to just use a random PDF that's out there (https://github.com/SuffolkLITLab/docassemble-EFSPIntegration/blob/1fca30c136ec4eaa8d8bf42fda52423bc6cac59b/docassemble/EFSPIntegration/test/opening_affidavit_adams.json#L1282). IMO the testing argument by itself isn't enough.

The security argument makes sense and could be swayed by it (though docassemble does that in general for most of its downloads IIRC?). But it makes parsing through the submission JSON much harder. It makes the changes I'm working on in SuffolkLITLab/docassemble-EFSPIntegration#310 kinda useless if there's going to be MBs of base64'd PDF data just hanging out in the JSON request.