Attachment API leads to high risk of leaking file handles

The AttachmentManager's API currently returns an InputStream from AttachmentManager.getAttachmentData(Attachment attachment). For the standard attachment-storage this returns a FileInputStream. It's the caller code's responsibility to close this InputStream and release the filehandle. There have been instances both in Confluence and plugins where this has not been done, leading to issues which are sometimes hard to track down.

Suggested fixes:
1) Instead of returning an InputStream, return something that provides an interface to do things with an InputStream and then closes it. Eg

// (off the top of my head)
class ClosingInputStreamProvider
{

public void doStuffWithInputStream(InputStreamClient client)
{
   try
   {
       InputStream stream = openStream();  // openStream would either call through to the attachmentManager or contain the code the attachmentManager contains now.
       client.doStuffWithStream();  // this would be the only way calling code could use the attachment input stream.
   }
   finally
   {
       IOUtils.closeQuietly(stream)
   }
}

2) Record the non closure of input streams. Log whenever a stream is opened and not closed within some period time. Maybe only do this when requested by admins.

3) both (since option 1 isn't immune to doStuffWithStream implementations blocking forever.)