V1 RecordingsPostHandler does not delete improperly-named files

[andrewazores]

Testing it now with your allocation_before_gc_fix.jfr. That should fail to upload to archives because the name pattern doesn't match, but it looks like it gets rejected with a 400 and yet the original UUID-named file corresponding to it is still present on the server. That's a bug in the V1 RecordingsPostHandler. I have renamed it to be similar to one of my other sample recordings that does have the correct name pattern, so now it is janlaw-6f4775cdbf-82dvl_10mb_20211006T152006Z.jfr. I'll see what's going on with this, but it definitely looks like the report generator container is just getting killed and restarted.

Originally posted by @andrewazores in https://github.com/cryostatio/cryostat/pull/779#discussion_r767016577

When a request to POST /api/v1/recordings is made and fails because the uploaded file had an improper file name, then the uploaded file in the file-uploads directory must be deleted from the server. Currently it is left dangling with a generated UUID name.

Reproducer sample:

$ https -f :8181/api/v1/recordings recording@foo.jfr
HTTP/1.1 400 Bad Request
content-encoding: gzip
content-length: 100
content-type: text/plain

Incorrect recording file name pattern caused by HttpStatusException: Bad Request


$ https :8181/api/v1/recordings
HTTP/1.1 200 OK
content-encoding: gzip
content-length: 141
content-type: text/plain

[
    {
        "downloadUrl": "https://localhost:8181/api/v1/recordings/857efa3a-1cab-4354-9720-10b0e125d228",
        "name": "857efa3a-1cab-4354-9720-10b0e125d228",
        "reportUrl": "https://localhost:8181/api/v1/reports/857efa3a-1cab-4354-9720-10b0e125d228"
    }
]