It looks like the addition of the directory-per-producer modification was
introduced in order to make the cleanup process easier for
SubscriptionRemovalHelper.java, since the code just needs to locate the
appropriate directory and then delete all of the files within.  

The original code had each resource (upon destruction) check the storage
directory, and delete it if empty.  This was subsequently removed as it could
cause potential race condition with another persistent subscription resource if
that resource also tried to remove or create the directory again at the same
time.

The existing code as commented suggests implementing a sweeper function to
periodically look for empty directories and remove them.  However, it seems
like this approach would also be prone to the same race condition.

The proposed solution is to remove the per-producer directory modification so
that the persistent directory structure is the same as 4.0.x series.  In other
words, there will be a single directory in which all of the persistent
subscriptions for the container will be stored.  

In order for this to work, the batch removal logic called by
SubscriptionRemovalHelper will have to modified to look for only the files
associated with the specified notification producer.  This should not be a
problem because in 4.2 the persisted object filename has the notification
producer key encoded into the filename, e.g.:

6D01551DC6F6D9E386FB98E76C112FA928627CBF+717f8df0-f788-11dc-ba3e-bcd76adc9d87.obj

In the above filename the string to the left of the "+" is the notification
producer key; so the strategy would be to obtain a list of the appropriate
files using Java FilenameFilter class, and then simply loop and delete them.

Fix committed to trunk.  Core notification tests all pass.  Martin, I will wait
for word from you on GRAM tests before closing this bug.

A simple job submission with staging showed that stuff is cleaned up
properly. didn't try a big submission yet.

Discussed with Martin, the fix worked, closing the bug.