ThreadPoolExecutor troubleshooting

[davidgyoung]

Includes several changes to help troubleshoot stalls in the ThreadPoolExecutor used to parse beacons.

1. Logs when we create a new ThreadPoolExecutor
2. Logs when we detect that a ThreadPoolExecutor is suspended unexpectedly
3. Recreates the ThreadPoolExecutor in the above case
4. Logs when we detect that a ThreadPoolExecutor has not processed anything in over 30 minutes. (This threshold is chosen because it is likely outside deep doze maintenance windows.)
5. Recreates the ThreadPoolExecutor in the above case
6. Logs how long processing has been queued on the ThreadPoolExecutor before we queue something new. This will typically be very close to 0 milliseconds.
7. Sends all of the above (except 6) to the API logs, so even if you lose LogCat, you will be able to see ThreadPoolExecutor events in the API logs as long as the process keeps running.

When using this, watch for log lines like these:

API ThreadPoolExecutor created
API ThreadPoolExecutor unexpectedly shut down
API ThreadPoolExecutor has stalled for %d millis.  Killing it.
ThreadPoolExecutor has not run in %d mill-is

This change also includes an optional mechanism to disable using AsyncTask structures to schedule beacon parsing on the ThreadPoolExecutor and instead use a plain Runnable. This may help if some complexities in the AsyncTask structure are causing a problem. To enable this optional change, call BeaconManager.useAsyncTask = false. I made this optional because I do not want to muddy the waters by making this change immediately.

The first and last lines are normal and expected. The others indicate problems and will trigger recovery attempts.

This change is available in library version 2.19.5-beta2 on MavenCentral

[davidgyoung]

Closed in favor of #1091.

The underlying problem suspected to be with the ThreadPoolExecutor ended up being with applying BeaconParser config changes, so a completely different solution was developed in the other PR.