chore: remove NoPerp tags to increase coverage

Signed-off-by: Elias Van Ootegem <[email protected]>

core/integration/features/fees/trading-fees-pdp.feature

@@ -651,7 +651,6 @@ Feature: Fees calculations
       | trader3 | ETH   | ETH/DEC21 | 240    | 9999766 |
       | trader4 | ETH   | ETH/DEC21 | 104    | 0       |
 
-  @NoPerp
   Scenario: WIP - Testing fees in continuous trading when insufficient balance in their general and margin account with LP, then the trade does not execute
     # <PC> - Just need to confirm if the trades doesn't go through, then general and margin account balances are expected to be 0.
     # <PC> - Also need to confirm if all 4 internal levels of margin should be 0, as in another case where the trade shouldn't be going through it's non-zero
@@ -675,7 +674,7 @@ Feature: Fees calculations
       | id        | quote name | asset | risk model          | margin calculator         | auction duration | fees          | price monitoring | data source config     | position decimal places | linear slippage factor | quadratic slippage factor | sla params |
       | ETH/DEC21 | ETH        | ETH   | simple-risk-model-1 | default-margin-calculator | 2                | fees-config-1 | price-monitoring | default-eth-for-future | 2                       | 0.25                   | 0                         | SLA        |
     And the following network parameters are set:
-      | name                                               | value |
+      | name                                             | value |
       | market.liquidity.providersFeeCalculationTimeStep | 10s   |
 
     # setup accounts
@@ -1037,7 +1036,6 @@ Feature: Fees calculations
       | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED |
 
 
-  @NoPerp
   Scenario: Testing fees in Price auction session trading with insufficient balance in their general and margin account, then the trade still goes ahead
     Given the liquidity monitoring parameters:
       | name               | triggering ratio | time window | scaling factor |
@@ -1254,7 +1252,6 @@ Feature: Fees calculations
       | trading mode            | auction trigger             |
       | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED |
 
-  @NoPerp
   Scenario: Testing fees in continuous trading during position resolution
 
     Given the fees configuration named "fees-config-1":

core/integration/features/liquidation/0012-POSR-012.feature

@@ -14,7 +14,7 @@ Feature: 0012-POSR-012 Update the liquidation strategy through market update
       | network.markPriceUpdateMaximumFrequency | 0s    |
       | limits.markets.maxPeggedOrders          | 2     |
 
-  @NoPerp @LiquidationUpdate
+  @LiquidationUpdate
   Scenario: Update liquidation strategy through market update
     # setup accounts
     Given the parties deposit on asset's general account the following amount:

core/integration/features/liquidity-provision/0044-LIME-088.feature

@@ -54,7 +54,7 @@ Feature: Test LP SLA Bond penalty on change of SLA market parameter: price range
       | market.liquidity.earlyExitPenalty                   | 0.25  |
 
     Given the average block duration is "1"
-  @Now @NoPerp
+  @Now
   Scenario: 001: If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their commitment and will not forfeit any of their bond stake. (0044-LIME-088)
     Given the parties deposit on asset's general account the following amount:
       | party  | asset | amount |

core/integration/features/liquidity-provision/0044-LIME-091.feature

@@ -62,7 +62,7 @@ Feature: Test change of SLA market parameter
       | market.liquidity.earlyExitPenalty                   | 0.25  |
 
     Given the average block duration is "1"
-  @Now @NoPerp
+  @Now
   Scenario: 001: lp1 and lp2 on the market ETH/MAR22, 0044-LIME-091, 0044-LIME-093, 0044-LIME-029
     Given the parties deposit on asset's general account the following amount:
       | party  | asset | amount |

core/integration/features/liquidity-provision/0044-LIME-113.feature

@@ -55,7 +55,7 @@ Feature: Test change of SLA market parameter
       | market.liquidity.earlyExitPenalty                   | 0.25  |
 
     Given the average block duration is "1"
-  @Now @NoPerp
+  @Now
   Scenario: 001: lp1 and lp2 on the market BTC/ETH, 0044-LIME-091, 0044-LIME-113, 0044-LIME-029, 0044-LIME-115
     Given the parties deposit on asset's general account the following amount:
       | party  | asset | amount |

core/integration/features/liquidity-provision/0044-LIME-115.feature

@@ -59,7 +59,7 @@ Feature: Test change of SLA market parameter
 
     Given the average block duration is "1"
 
-  @Now @NoPerp
+  @Now
   Scenario: 001: lp1 and lp2 on the market BTC/ETH, 0044-LIME-091, 0044-LIME-115
     Given the parties deposit on asset's general account the following amount:
       | party  | asset | amount |

core/integration/features/orders/stoporders.feature

@@ -598,7 +598,6 @@ Feature: stop orders
       | party  | market id | side | volume | remaining | price | status        | reference |
       | party1 | ETH/DEC19 | buy  | 10     | 0         | 0     | STATUS_FILLED | stop1     |
 
-  @NoPerp
   Scenario: If the order is triggered before reaching time T, the order will have been removed and will not trigger at time T. (0014-ORDT-054) (0014-ORDT-041)
 
     # setup accounts
@@ -1625,7 +1624,6 @@ Feature: stop orders
       | party1 | 1      | 10             | 0            |
 
 
-  @NoPerp
   Scenario: If the order is triggered before reaching time T, the order will have been removed and will not trigger at time T. (0014-ORDT-054) (0014-ORDT-041)
 
     # setup accounts

core/integration/features/position_tracking/verified-positions-resolution-5-lognormal_pdp.feature

@@ -24,7 +24,7 @@ Feature: Position resolution case 5 lognormal risk model
       | network.markPriceUpdateMaximumFrequency | 0s    |
       | limits.markets.maxPeggedOrders          | 2     |
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: using lognormal risk model, set "designatedLoser " closeout while the position of "designatedLoser " is not fully covered by orders on the order book
     # setup accounts
     Given the parties deposit on asset's general account the following amount:

core/integration/features/price_monitoring/price-monitoring-bounds.feature

@@ -128,7 +128,7 @@ Feature: Price monitoring triggers test on or around monitoring bounds with deci
       | mark price  | trading mode            | target stake     | supplied stake   | open interest |
       | 10015612114 | TRADING_MODE_CONTINUOUS | 1489121209109520 | 9000000000000000 | 2             |
 
-  @PriceBounds @NoPerp
+  @PriceBounds
   Scenario: Trades below minimum price bound by 1 after an update to the price monitoring parameters
     Given the parties deposit on asset's general account the following amount:
       | party  | asset | amount                     |
@@ -189,7 +189,7 @@ Feature: Price monitoring triggers test on or around monitoring bounds with deci
       | mark price | trading mode            | target stake     | supplied stake   | open interest |
       | 9000000000 | TRADING_MODE_CONTINUOUS | 1338120000000000 | 9000000000000000 | 2             |
 
-  @PriceBounds @NoPerp
+  @PriceBounds
   Scenario: Trades above maximum price bound by 1 decimal after market update
     Given the parties deposit on asset's general account the following amount:
       | party  | asset | amount                     |

core/integration/features/rewards/average_position_with_liquidation_reward.feature

@@ -51,7 +51,7 @@ Feature: Calculation of average position during closeout trades
         When the network moves ahead "1" blocks
         And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/USD-1-10"
 
-    @Liquidation @NoPerp
+    @Liquidation
     Scenario: Bug time-weighted average position not updated correctly during closeout trades
         # Setup such that distributed rewards are all vested the following epoch, i,e. the balance in the vested account is equal to the rewards distributed that epocha
 

core/integration/features/settlement/mark_to_market_interval_positions.feature

@@ -25,7 +25,7 @@ Feature: Check position tracking matches expected behaviour with MTM intervals.
       | network.markPriceUpdateMaximumFrequency | 5s    |
       | limits.markets.maxPeggedOrders          | 2     |
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: 001, using lognormal risk model, set "designatedLoser" closeout while the position of "designatedLoser" is not fully covered by orders on the order book (0007-POSN-013)
     # setup accounts
     Given the parties deposit on asset's general account the following amount:
@@ -199,7 +199,7 @@ Feature: Check position tracking matches expected behaviour with MTM intervals.
 
     And the insurance pool balance should be "0" for the market "ETH/DEC19"
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: 002, closeout trade with price outside price mornitoring bounds will not trigger auction 0032-PRIM-019
     # setup accounts
     Given the parties deposit on asset's general account the following amount:
@@ -352,7 +352,6 @@ Feature: Check position tracking matches expected behaviour with MTM intervals.
       | party           | asset | market id | margin | general |
       | designatedLoser | USD   | ETH/DEC20 | 0      | 0       |
 
-  @NoPerp
   Scenario: 003, settlement works correctly when party enters and leaves within one MTM window
     Given the liquidity sla params named "SLA":
       | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor |

core/integration/features/verified/0003-MTMK-mark_to_market_settlement_using_insurance_pool.feature

@@ -10,7 +10,7 @@ Feature: Test mark to market settlement with insurance pool
       | network.markPriceUpdateMaximumFrequency | 0s    |
       | limits.markets.maxPeggedOrders          | 2     |
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: If settlement amount > party’s margin account balance + party’s general account balance for the asset, the full balance of the party’s margin account is transferred to the market’s temporary settlement account, the full balance of the party’s general account for the assets are transferred to the market’s temporary settlement account, the minimum insurance pool account balance for the market & asset, and the remainder, i.e. the difference between the total amount transferred from the trader’s margin + general accounts and the settlement amount, is transferred from the insurance pool account for the market to the temporary settlement account for the market (0003-MTMK-003)
     Given the initial insurance pool balance is "10000" for all the markets
     Given the parties deposit on asset's general account the following amount:

core/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature

@@ -1,6 +1,6 @@
 Feature: Test closeout type 1: margin >= cost of closeout
 
-  @NoPerp @PanicDebug
+  @PanicDebug
   Scenario: case 1 (using simple risk model) from https://docs.google.com/spreadsheets/d/1CIPH0aQmIKj6YeFW9ApP_l-jwB4OcsNQ/edit#gid=1555964910 (0015-INSR-001, 0015-INSR-003, 0018-RSKM-001, 0018-RSKM-003, 0010-MARG-004, 0010-MARG-005, 0010-MARG-006, 0010-MARG-007, 0010-MARG-008. 0010-MARG-009)
     Given the simple risk model named "simple-risk-model-1":
       | long | short | max move up | min move down | probability of trading |

core/integration/features/verified/0029-FEES-trading_fees.feature

@@ -523,7 +523,6 @@ Feature: Fees calculations
       | party   | market id | maintenance | search | initial | release |
       | trader4 | ETH/DEC21 | 0 | 0 | 0 | 0 |
 
-  @NoPerp
   Scenario: S008, Testing fees in continuous trading when insufficient balance in their general and margin account with LP, then the trade does not execute (0029-FEES-007，0029-FEES-008)
     And the markets:
       | id        | quote name | asset | risk model          | margin calculator         | auction duration | fees          | price monitoring | data source config     | linear slippage factor | quadratic slippage factor | sla params      |
@@ -980,7 +979,7 @@ Feature: Fees calculations
       | trading mode            | auction trigger             |
       | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED |
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario:S016,  Testing fees in Price auction session trading with insufficient balance in their general and margin account, then the trade still goes ahead (0029-FEES-008)
 
     And the average block duration is "1"
@@ -1160,7 +1159,7 @@ Feature: Fees calculations
       | trading mode            | auction trigger             |
       | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED |
 
-  @now @Liquidation @NoPerp
+  @now @Liquidation
   Scenario: S018, Testing fees in continuous trading during position resolution (0029-FEES-001)
 
     Given the fees configuration named "fees-config-1":
@@ -1254,7 +1253,7 @@ Feature: Fees calculations
 
     And the insurance pool balance should be "0" for the market "ETH/DEC21"
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: S019, Testing fees in continuous trading during position resolution with insufficient balance in their general and margin account, partial or full fees does not get paid (0029-FEES-008)
 
     Given the fees configuration named "fees-config-1":

core/integration/features/verified/0041-TSK-target_stake.feature

@@ -42,7 +42,6 @@ Feature: Target stake
       | tt_3  | BTC   | 100000000 |
       | tt_4  | BTC   | 100000000 |
 
-  @NoPerp
   Scenario: Max open interest changes over time (0041-TSTK-002, 0041-TSTK-003, 0042-LIQF-007)
 
     Given the liquidity monitoring parameters:
@@ -211,7 +210,6 @@ Feature: Target stake
       | 110        | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 0            | 2000           | 0             |
     And the liquidity fee factor should be "0.001" for the market "ETH/DEC21"
 
-  @NoPerp
   Scenario: Max open interest changes over time, testing change of timewindow (0041-TSTK-001; 0041-TSTK-004; 0041-TSTK-005)
 
     Given the liquidity monitoring parameters:
@@ -307,7 +305,6 @@ Feature: Target stake
     # target_stake = 110 x (140+30) x 170 x 1 x 0.1=1870
     And the target stake should be "1870" for the market "ETH/DEC21"
 
-  @NoPerp
   Scenario: Target stake is calculate correctly during auction in presence of wash trades
 
     Given the liquidity monitoring parameters:
@@ -359,7 +356,6 @@ Feature: Target stake
       | mark price | trading mode            | auction trigger             | target stake | supplied stake | open interest |
       | 110        | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 550          | 2000           | 50            |
 
-  @NoPerp
   Scenario: Target stake can drop during auction
 
     Given the liquidity monitoring parameters:

core/integration/features/verified/0042-LIQF-fees_rewards_VirtualStake.feature

@@ -477,7 +477,7 @@ Feature: Test liquidity provider reward distribution; Should also cover liquidit
 
     And the accumulated liquidity fees should be "1" for the market "ETH/MAR22"
 
-  @FeeRound @Liquidation @NoPerp
+  @FeeRound @Liquidation
   Scenario: 004 2 LPs joining at start, 1 LP forcibly closed out (0042-LIQF-008)
 
     Given the average block duration is "601"

core/integration/features/verified/closeout-LP_New_Exit_Price.feature

@@ -30,7 +30,7 @@ Feature: Replicate a scenario from Lewis with Elias' implementation on Exit_pric
       | limits.markets.maxPeggedOrders          | 2     |
     And the average block duration is "1"
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: 001 Replicate a scenario from Lewis with Elias' implementation on Exit_price when there is insufficient orders, linear slippage factor = 1e6, quadratic slippage factor = 1e6, 0019-MCAL-001, 0019-MCAL-002
     # 1. trader B made LP commitment 150,000
     # 2. trader C and A cross at 0.5 with size of 111, and this opens continuous trading (trade B is short)

core/integration/features/verified/closeout-cascade.feature

@@ -19,7 +19,7 @@ Feature: Closeout-cascades
       | limits.markets.maxPeggedOrders          | 2     |
 
   @NetworkParty
-  @CloseOutTrades @Liquidation @NoPerp
+  @CloseOutTrades @Liquidation
   Scenario: Distressed position gets taken over by another party whose margin level is insufficient to support it (however mark price doesn't get updated on closeout trade and hence no further closeouts are carried out) (0005-COLL-002)
     # setup accounts, we are trying to closeout trader3 first and then trader2
 

core/integration/features/verified/closeout-lognormal.feature

@@ -21,7 +21,7 @@ Feature: Closeout scenarios
       | network.markPriceUpdateMaximumFrequency | 0s    |
       | limits.markets.maxPeggedOrders          | 2     |
 
-  @EndBlock @Liquidation @NoPerp
+  @EndBlock @Liquidation
   Scenario: 001, 2 parties get close-out at the same time. Distressed position gets taken over by LP, distressed order gets canceled (0005-COLL-002; 0012-POSR-001; 0012-POSR-002; 0012-POSR-004; 0012-POSR-005; 0007-POSN-015)
     # setup accounts, we are trying to closeout trader3 first and then trader2
 

core/integration/features/verified/liquidity-provision-bond-account.feature

@@ -34,7 +34,7 @@ Feature: Replicate LP getting distressed during continuous trading, check if pen
       | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0    |
 
 
-  @Now @NoPerp
+  @Now
   Scenario: 001, LP gets distressed during continuous trading, no DPD setting (0044-LIME-002, 0035-LIQM-004)
 
     Given the liquidity monitoring parameters:

core/integration/features/verified/risk-parameters-ranges-test.feature

@@ -124,7 +124,7 @@ Feature: test risk model parameter ranges
       | network.markPriceUpdateMaximumFrequency | 0s    |
       | limits.markets.maxPeggedOrders          | 22    |
 
-  @Now @NoPerp @SLABug
+  @Now @SLABug
   Scenario: 001, test different value of risk parameters within defined ranges in different market, AC: 0018-RSKM-001
 
     Given the liquidity monitoring parameters:
@@ -452,7 +452,7 @@ Feature: test risk model parameter ranges
       | party1 | USD   | ETH/MAR51 | 3021   | 49999999875869 |       |
       | party2 | USD   | ETH/MAR51 | 3021   | 49999999584845 |       |
 
-@Now @NoPerp
+  @Now
   Scenario: 002, test market ETH/MAR23 (tau=1)
 
     Given the liquidity monitoring parameters:
@@ -519,7 +519,7 @@ Feature: test risk model parameter ranges
 
   # initial margin level for LP = 1000*9092*86.2176101*1.2=9.4e8
 
-  @Now @NoPerp
+  @Now
   Scenario: 003, test market ETH/MAR52(sigma=10),
 
     Given the liquidity monitoring parameters:

core/integration/features/verified/risk-parameters-sigma-test.feature

@@ -41,7 +41,7 @@ Feature: test risk model parameter sigma
       | network.markPriceUpdateMaximumFrequency | 0s    |
       | limits.markets.maxPeggedOrders          | 2     |
 
-  @Now @NoPerp
+  @Now
   Scenario: 001, test market ETH/MAR53(sigma=50),
 
     Given the liquidity monitoring parameters:
@@ -101,7 +101,7 @@ Feature: test risk model parameter sigma
       | party  | market id | maintenance    | search         | initial        | release        |
       | party0 | ETH/MAR53 | 49999950000000 | 59999940000000 | 74999925000000 | 84999915000000 |
 
-  @Now @NoPerp
+  @Now
   Scenario: 002, test market ETH/MAR0 (kind of "normal" risk parameters setting),
 
     Given the liquidity monitoring parameters:

core/integration/features/verified/verified-positions-resolution-2.feature

@@ -9,7 +9,7 @@ Feature: Position resolution case 2
       | market.auction.minimumDuration          | 1     |
       | network.markPriceUpdateMaximumFrequency | 0s    |
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: close out when there is not enough orders on the orderbook to cover the position (0008-TRAD-003, 0008-TRAD-004)
     # setup accounts
     Given the parties deposit on asset's general account the following amount:

core/integration/features/verified/verified-positions-resolution-3.feature

@@ -9,7 +9,7 @@ Feature: Position resolution case 3
       | market.auction.minimumDuration          | 1     |
       | network.markPriceUpdateMaximumFrequency | 0s    |
 
-  @Liquidation @NoPerp
+  @Liquidation
   Scenario: close out when there is enough orders on the orderbook to cover the position (0008-TRAD-002,0008-TRAD-003, 0008-TRAD-006)
     # setup accounts
     Given the parties deposit on asset's general account the following amount:

core/integration/features/zero-position.feature

@@ -21,7 +21,7 @@ Feature: Closeout scenarios
       | network.markPriceUpdateMaximumFrequency | 0s    |
       | limits.markets.maxPeggedOrders          | 2     |
 
-  @ZeroPos @Liquidation @NoPerp
+  @ZeroPos @Liquidation
   Scenario: 001, 2 parties get close-out at the same time. Distressed position gets taken over by LP, distressed order gets canceled (0005-COLL-002; 0012-POSR-001; 0012-POSR-002; 0012-POSR-004; 0012-POSR-005; 0007-POSN-015)
     # setup accounts, we are trying to closeout trader3 first and then trader2