Integration tests behave differently to the application with respect to HibernateSession

### Feature description

If we run a Grails application the OISV pattern means that we always have a HibernateSession associated with the thread.

INSERT and SELECT calls inside a service class that are not marked @Transactional will work because a transaction is not mandatory. For an INSERT you can call domainObject.save() and that will not complain, but if you call DomainObject.save(flush:true) it will complain that you need to have a transaction. So far so good.

However in an integration test if you do not have the @Rollabck annotation you have neither a Session nor a Transaction. If in an integration test you call an application method that does a SELECT - i.e. something that works in a running application - the integration test will fail with "No HibernateSession bound to thread.

If on the other hand, if you add a @Rollback annotation to the test, that provides a session, but also starts a transaction. In that case a service method in the application that does not have @Transaction, but does DomainObject.save(flush:true) will fail in the application at runtime, but succeed in the integration test - because there is a transaction provided by the test.

So - as far as I am aware - its not immediately easy to have an integration test that runs application code with the same transactional context that the application has. Depending on whether you add @Rollback or not you can get tests that fail when thy should pass and vice versa.

Best I could come up with is to not have @Rollback on the integration test and spray a lot of `DomainObject.withNewSession { test code here}` into the test - but that is horrible if using Spock.

It would be nice if by default the integration test bound a HIbernateSession to the test thread - i.e. provide a transaction context that aligns with the application.

If not by default then perhaps as an annotation @WithSession - or similar

Start by reproducing the integration-test cases described: run application SELECT and save(flush:true) calls with and without @Rollback, then inspect how the HibernateSession is bound to the test thread. Compare that behavior with the running application and determine whether the default or annotation-based context is intended. Done means integration tests exercise application code under matching session and transaction semantics without repeated withNewSession blocks.

Written by the indexing model from the issue text.