Answer HEAD from the file's size when send_file would send it as it is

[sdogruyol]

The "separate" half of #803.

Description of the Change

HeadRequestHandler swaps the response output for a counting NullIO and runs the GET handler; Content-Length is whatever got written. For send_file that means a HEAD on a 20 GB file reads 20 GB off disk to count them. Measured with /proc/self/io on a 50 MiB file: HEAD read 50.0 MiB.

When the stored bytes go out as they are — coding.nil?, i.e. no on-the-fly compression, which also covers the pre-compressed .gz neighbour StaticFileHandler substitutes — the length is File.info.size, already in hand. send_file now sets Content-Length and returns before opening the body for copying. After: 0.0001 MiB read.

Two deliberate limits:

• The file is still opened (File.open(file_path) { }, no read). A HEAD has to fail where the GET fails; otherwise it would report 200 and the size of a file the GET answers 404 for (Report an unreadable static file as 404, as the stdlib does #799). One open/close syscall, no bytes.
• A body Kemal compresses is still produced. Its length isn't knowable without producing it, and head_request_handler_spec.cr:25 pins that a gzip HEAD reports the compressed length. Unchanged.

Verification

• New spec: HEAD on a 4 MiB file → 200, empty body, Content-Length: 4194304 (portable).
• New spec, Linux only (/proc/self/io): the HEAD reads under 1 MiB. Fails on master with 4194402 bytes read.
• Extended the unreadable-file spec: HEAD on a mode-000 file is 404 like the GET.
• Full suite green (498), -Dwithout_zlib green (467), ameba and format clean.