v3: Run usage event-purging specs in isolation: truncation mode

When we added these tests recently, we started seeing lots of random
other failures in CI when run against MySQL. It seemed to be a test
pollution issue (other tests were seeing DB entries they didn't expect,
or were missing DB entries that they did expect).

After talking to the CAPI team, we learned that the table truncation
performed by these new endpoints may change the mode that tests are run
in. Usually, they are run in a transaction that gets rolled back
automatically, so we avoid pollution. But this truncation may change
that.

To fix it, we are attempting here to run these new truncating tests with
`isolation: :truncation`, to keep them better isolated and avoid test
pollution.

Authored-by: Reid Mitchell <rmitchell@pivotal.io>

Author: reidmit

spec/request/app_usage_events_spec.rb

@@ -117,7 +117,7 @@
     end
   end
 
-  describe 'POST /v3/app_usage_events/actions/destructively_purge_all_and_reseed' do
+  describe 'POST /v3/app_usage_events/actions/destructively_purge_all_and_reseed', isolation: :truncation do
     let(:api_call) { lambda { |user_headers| post '/v3/app_usage_events/actions/destructively_purge_all_and_reseed', nil, user_headers } }
     let(:app_model) { VCAP::CloudController::AppModel.make(space: space) }
 

spec/request/service_usage_events_spec.rb

@@ -148,7 +148,7 @@
     end
   end
 
-  describe 'POST /v3/service_usage_events/actions/destructively_purge_all_and_reseed' do
+  describe 'POST /v3/service_usage_events/actions/destructively_purge_all_and_reseed', isolation: :truncation do
     let(:api_call) { lambda { |user_headers| post '/v3/service_usage_events/actions/destructively_purge_all_and_reseed', nil, user_headers } }
 
     let!(:service_instance) do