Lockdown firebase arrays and improve index add performance

[SUPERCILEX]

Here's my reasoning behind the change:

1. Our classes aren't extensible anyway.
   I'm personally a culprit here, I've never really bothered thinking about how devs would extend our firebase arrays. Take the FirebaseIndexArray for example. Let's say a developer wants to override onKeyAdded:
   

   FirebaseUI-Android/database/src/main/java/com/firebase/ui/database/FirebaseIndexArray.java

   Lines 178 to 185 in d871c7a

   	protected void onKeyAdded(DataSnapshot data) {
   	String key = data.getKey();
   	DatabaseReference ref = mDataRef.child(key);
   	mKeysWithPendingUpdate.add(key);
   	// Start listening
   	mRefs.put(ref, ref.addValueEventListener(new DataRefListener()));
   	}

   
   All of the fields referenced in there are private so the developer would also have to override onKey[Changed/Removed/Moved]. Since they had to reimplement those methods, they also have to reimplement DataRefListener since it accesses private fields. And then all the other methods are private so at this point the developer has just reimplemented the whole class and there's no point in extending it in the first place. As for getting the callbacks, they should just be using our ChangeEventListener api.
2. It hinders improvements.
   As you can see in this PR, I was able to improve performance by breaking backwards compatibility.
3. Favor composition over inheritance.
   Using inheritance (on lists especially) is poor practice and we should encourage developers to use inheritance.

[SUPERCILEX]

@samtstern Could you make a 3.0 branch please?

To address your comment:

Making methods private is probably a good thing, but making the class final means that you can't test this class with mocking, which is a pain. For that reason I don't really like using final except on fields.

You can mock final symbols, it's just not a stable api yet. Does that work?

[samtstern]

The mocking of final things does not play nice with Android, I tried really hard to get it to work before giving up :-(

And yep, will make that branch. Will branch 3.0 from 2.3.1-dev to start

[samtstern]

https://github.com/firebase/FirebaseUI-Android/tree/version-3.0.0-dev

[SUPERCILEX]

@samtstern Oh well, that's too bad. 😢 I'll make the classes non-final and keep the other changes.

[samtstern]

Missed one!

[SUPERCILEX]

That shouldn't matter, right? We're making it private so it's not mockable anyway.

[Kurt29]

I dont't want to bother you, but wanted to ask why this approach is more efficient?

[SUPERCILEX]

@Eragon29 we don't have to query for the correct index on addition.

[Kurt29]

@SUPERCILEX Ah, now I get it.
I think I am just not used to see code like
int index = currentIndex = returnOrFindIndexForKey(currentIndex, key);
in Java. After that looking at the method returnOrFindIndexForKey(index, key) was enough.

[SUPERCILEX]

👍