Create awareness around token entries disk usage on PostgreSQL in the documentation when using the JPA implementation

[hatzlj]

There has been a broader discussion on the use of PostgreSQL with the JPA Token store in the axon google group some time ago regarding binary storage of the tokens (see https://groups.google.com/forum/#!msg/axonframework/HhzQMbWfHTg/G04WbiixBAAJ)

We and apparently other users (e.g. @rcusters) have stumbled across this issue, but only after running our applications for some time (in production). I assume this is because the effects of the growing large-object table only show up when running an application for quite some time.

Altough it does not seem to be a problem that needs to be solved in the Axon framework, it could still be helpful for new users to point out the implications of using the JPATokenStore with hibernate and postgres in the standard configuration to avoid migrations and maintenance later and already implement a strategy during development.

I suggest to add an explanation (condensed from the discussion in the google group) and some hints/strategies to overcome (remap to bytea, use vacuumlo daemon) in the Axon reference-guide under the production considerations section (see https://github.com/AxonIQ/reference-guide/tree/master/operations-guide/production-considerations).

referencing: AxonFramework/AxonFramework#1351

[smcvb]

Another topic which should be shared when this information is added to the appendices, is the fact you can omit the use of TOAST/OID entirely from PostgreSQL. A sample on how to reach this can be found here.