Use aliases for ES browse index for future-proofing.

[yossariano]

• Instead of changing the name of the index in our config every time we make a new one and reindex, this change just points to an alias that won't change (even if what that alias points to changes).
• I already hooked these aliases up to the current in-use browse indices in QA and prod, but I'm anticipating needing to hot-swap some indices in the future and this gives us that flexibility.

[nonword]

We used aliases for the resources index in the past, but found that when index schema changes accompanied code changes, it was actually helpful to have the code reference an explicit index. With aliases, if schema changes necessitate code changes, we'll need to carefully coordinate deployments and alias updates to minimize the window in which legacy code is using the newer schema - or vice versa. But that's only a problem when index changes include breaking schema changes, which may not be the case for the terms work to date.

[yossariano]

We used aliases for the resources index in the past, but found that when index schema changes accompanied code changes, it was actually helpful to have the code reference an explicit index. With aliases, if schema changes necessitate code changes, we'll need to carefully coordinate deployments and alias updates to minimize the window in which legacy code is using the newer schema - or vice versa. But that's only a problem when index changes include breaking schema changes, which may not be the case for the terms work to date.

This isn't urgently needed- after some more discussions today I think I'll just put a pin in this for now. We can all chat as a group about what role (if any) ES aliases could give us- I see the value in keeping it more explicit for the time being.