NLU module updates, threaded through the Spokestack wrapper

[space-pope]

I'd like an API sanity check here—see if the commit message pasted below makes sense. Further explanation: I think we need to keep Spokestack.start() and stop() limited to interacting with the speech pipeline—a user might want to force the pipeline to stop listening while playing a TTS prompt, so stop() can't call close() on TTS—but it would also be good to have the ability to fully release all modules' resources if necessary.

Would it be less surprising if start() also ran prepare() implicitly?

---

This change makes the NLUService extend AutoCloseable, which forces a
close() method on all implementors. The existing service uses this to
release TensorFlow model and vocab resources.

On the NLU manager, close() has been duplicated as a convenience
method called release(), named for parallelism with the newly
added prepare() method, which is its inverse.

The NLU module was the last one to provide release/prepare
support, so adding it suggests a change to the Spokestack wrapper
API, removing the release/prepare methods used for the TTS module
and repurposing them to handle resources for both NLU and TTS.

[noelweichbrodt]

I know I wasn't tagged, but have a couple of comments. I agree with the sentiment, and AutoCloseable is a reasonable thing to implement to add clarity to resource management, but it does bother me that there's two different semantics in use (stop/start & prepare/release). Additionally, unclear how initialize relates to this change (from a client's perspective). Finally, if you came across a use case from the tray work that motivated this change, it would be good to share that.

[noelweichbrodt]

Suggested change

	* Spokestack, see {@link #release()}.
	* the Spokestack pipeline, see {@link #release()}.

[space-pope]

Saying "the Spokestack pipeline" here introduces confusion between Spokestack (a collection of all modules), and the speech pipeline. This is meant to refer to the former.

[space-pope]

I agree with the start/stop vs prepare/release problem. It stems from tension between Spokestack originally being just a speech pipeline (and the fact that that's arguably still its primary/most valuable function) and the fact that it's grown into a larger system.

Because of the primacy of the speech pipeline, I think it's still useful to think of start/stop as things that relate only to the app "listening" to the user. I'd be open to making those methods manage resources for other subsystems (and almost did), were it not for the fact that the speech pipeline might need to be managed separately from other modules—as I mentioned in the PR message, you might want to stop the speech pipeline from listening while the TTS module is active (so you can't release its resources).

Another possibility I didn't touch on here is that of expanding the speech pipeline API to more closely resemble Python's. Including a pause method would take a little refactoring in the pipeline but allow the scenario I mentioned above while letting start/stop take over all resource management duties. The only question left then is whether start/stop are good names for methods in charge of application resources. Personally, I'm not a big fan.

[space-pope]

Oh, and I'm not sure what you're referring to with initialize—that's not a method name in use anywhere in the Android lib. Initialization in Java is usually synonymous with object construction; that's how it's used in the docs.

Edit: I missed your last sentence on my first read-through. This change isn't motivated by the tray, but by me noticing that there was no way for an application to temporarily release resources held by the NLU module, but the other modules supported this use pattern. Once I'd put the modules on equal footing, it made sense to modify the wrapper to expose the full functionality.

[brentspell]

The main purpose of the start/stop states are to minimize resource usage in the application when the speech features have been disabled. If you want to be able to stop listening during tts while not tearing everything down, it would probably make sense to add the pause/resume functions to the pipeline and then automatically call them in your spokestack wrapper during tts.

[space-pope]

In consideration of the feedback here, prepare and release have been removed, their functionality taken over by start and stop, respectively. The speech pipeline can now be temporarily paused, and that functionality has been threaded through the wrapper. pause and resume can be called manually, but they are called automatically when TTS events are received.

[brentspell]

this looks like a simple solution, nice work